https://pantsbuild.org/ logo
Powered by
b

bitter-ability-32190

06/02/2022, 12:51 AM
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

happy-kitchen-89482

06/02/2022, 6:23 AM
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

bitter-ability-32190

06/02/2022, 9:53 AM
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

clean-city-64472

06/02/2022, 3:15 PM
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

witty-crayon-22786

06/02/2022, 4:44 PM
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

bitter-ability-32190

06/02/2022, 7:00 PM
Normal git commands work fine, it's just a pants issue.
From a colleague. Seeing if restarting the daemon works
c

clean-city-64472

06/02/2022, 9:04 PM
@witty-crayon-22786 
git
commands worked in 
CWD
and when running commands with 
-no-pantsd
. I only saw the error when using 
pantsd
w

witty-crayon-22786

06/02/2022, 9:06 PM
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

clean-city-64472

06/02/2022, 9:09 PM
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

bitter-ability-32190

06/02/2022, 9:09 PM
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

clean-city-64472

06/02/2022, 9:10 PM
Oh that’s fair, I had to kill pantsd after I chnaged 
/etc/gitconfig
to verify the fix
w

witty-crayon-22786

06/02/2022, 9:11 PM
hm. yea, that’s definitely a bug. things did change there recently… which version(s) of pants is this?
b

bitter-ability-32190

06/02/2022, 9:11 PM
w

witty-crayon-22786

06/02/2022, 9:11 PM
*of pants ?
😂 1
b

bitter-ability-32190

06/02/2022, 9:12 PM
My peeps are 2.11
c

clean-city-64472

06/02/2022, 9:20 PM
2.9.2
but was also happening on 
2.9.0rc3
w

witty-crayon-22786

06/02/2022, 9:20 PM
ok: it’s possible that the stickiness is actually fixed on main
b

bitter-ability-32190

06/02/2022, 9:21 PM
Yeah thats my original question. 🙈
w

witty-crayon-22786

06/02/2022, 9:21 PM
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
Powered by