https://pantsbuild.org/ logo
Join Slack
Powered by
Had a user see: ```22:21:50.71 [ERROR] 1 Exception...
# development
b
Had a user see:
Copy code
22:21:50.71 [ERROR] 1 Exception encountered:

  AssertionError:

22:21:50.77 [INFO] Canceled: Building pylint.pex from 3rdparty/python/lockfiles/pylint.txt
Which turned out with 
-ldebug
to be
Copy code
22:38:30.63 [INFO] No git repository at /home/firstnamelastname/work/repo: GitException("fatal: unsafe repository ('/home/firstnamelastname/work/repo' is owned by someone else)\nTo add an exception for this directory, call:\n\n\tgit config --global --add safe.directory /home/firstnamelastname/work/repo\n")
@happy-kitchen-89482 is this still an issue in the new Git code? Or should I file an issue and fix?
h
The new git code is just using the Python package 
setuptools_scm
, which itself delegates to 
git
CLI. So I don't think it's relevant? But why is git being invoked at all in this run? Is that user using 
--changed
flags?
b
Yes to changed. I think it's relevant because in the end the same underlying problem is to blame.
I realize now I didn't explicitly say that by fixed I mean we have a nice and easy error for the user to action on
c
I’m wrestling with this issue right now too
It works with 
no-pantsd
so I believe it’s something to do with the user running the process not having access to the repo…
To get it to work with 
no-pantsd
I had to run this (also just to get anything in git to work) 
git config --global --add safe.directory /repodir
config --global
seems to make entries in 
~/.gitconfig
so it doesn’t really seem to be global - more like user level config.
Ok looks like you can manually create 
/etc/gitconfig
in the format of 
~/.gitconfig
and use that to mark the repo safe globally (in the true sense). That resolves the issue for me.
w
hm. do we think that this is related to how pants is invoking 
git
(with an explicitly specified workdir?) or is this easily reproducible outside of pants?
❗ 1
b
Normal git commands work fine, it's just a pants issue.
From a colleague. Seeing if restarting the daemon works
c
@witty-crayon-22786 
git
commands worked in 
CWD
and when running commands with 
-no-pantsd
. I only saw the error when using 
pantsd
w
hm… filing an issue with any other details you have would be great. git version, the actual git command that is failing (unfortunately, it looks like even the debug output does not include the command, so would maybe need to run in source mode), etc.
c
I’m not sure it’s necessarily a pants bug, it may just be the new cost of doing business with this new git security model
b
I think it's both? The daemon is caching operations that are no longer valid due to changing filesystem. Likely Pants shouldn't cache the git operation?
c
Oh that’s fair, I had to kill pantsd after I chnaged 
/etc/gitconfig
to verify the fix
w
hm. yea, that’s definitely a bug. things did change there recently… which version(s) of pants is this?
b
w
*of pants ?
😂 1
b
My peeps are 2.11
c
2.9.2
but was also happening on 
2.9.0rc3
w
ok: it’s possible that the stickiness is actually fixed on main
b
Yeah thats my original question. 🙈
w
but need a bit more info to repro
@bitter-ability-32190: yea. it just wouldn’t have been Benjy’s change: rather, this one: https://github.com/pantsbuild/pants/pull/15030
👀 1
✅ 1
🙌 1
unclear though… the actual caching semantics there were delicate (less delicate than global statics, but still!), and this case is an odd one which might look like a non-existent repo
Open in Slack
PreviousNext
Powered by