https://pantsbuild.org/ logo
Join Slack
Powered by
I am trying to run some pytests with pants 2.0.2. ...
# general
s
I am trying to run some pytests with pants 2.0.2. These specific tests run a subprocess command in a function that interacts with 
git
. I am getting the following error:
Copy code
fatal: not a git repository (or any of the parent directories): .git
I have found that this is because with pants 2 the root where the tests run is
Copy code
/private/var/folders/89/r169_6497n15qnqm0bfhnjlr0000gp/T/process-executionzY6hQB
which does not include my “.git” config files. With pants v1 all of these tests ran without issue and im assuming the root was the “build root”. I have tried adding a global 
resource
that includes the 
git
files necessary but that is not working. Is this as simple as changing the 
rootdir
of the global pants options? I would like to not have things running “inside” of my build root as it could cause other issues. Any other suggestions?
e
Well, not too satisfying - ie: no Pants magic, but one route is to re-write the tests to be hermetic and set up their own git repo. For example: https://github.com/pantsbuild/pants/blob/main/src/python/pants/vcs/git_test.py
h
Alternatively, having test 
.git
files checked in as resources should work, although there may be some futzing with the paths.
e
A thrird option is to plumb GIT_DIR and GIT_WORK_TREE env vars to point back at the build root. I'm not sure if this can be done portably with pants. Perhaps via pants.toml which supports "$(buildroot)s" interpolation.
Concretely, this would be the pants.toml edit in the pants repo itself:
Copy code
$ git diff
diff --git a/pants.toml b/pants.toml
index 985d8734e..05febd0aa 100644
--- a/pants.toml
+++ b/pants.toml
@@ -163,6 +163,8 @@ extra_env_vars = [
   "PATH",
   # We'd always like complete backtraces in tests.
   "RUST_BACKTRACE=1",
+  "GIT_DIR=%(buildroot)s/.git",
+  "GIT_WORK_TREE=%(buildroot)s",
 ]
 
 [coverage-py]
h
Resources won't work because pants_ignore option ignores .git, which is necessary to keep I believe
John's recommendation sounds good. Only issue I see is that it will cache when it may not be safe - pants won't be able to track when the .git folder should change I think we'd need to add a field to python_tests to mark the tests as uncacheable
e
The env var value is part of the cache key, so things should just work.
h
But the env var doesn't change when .git folder changes, right?
e
Aha, yes - Eric is right if the tests depend on the state of the git repo.
If they just use it to branch from a known old commit, do some work, then clean up, you should be good.
👍 1
🔥 1
s
all my tests do not depend on state so this will work! thanks guys as always
❤️ 1
I will let you know how it works out
🤞 1
h
@hundreds-father-404 This wouldn't be the real 
.git
but a test one that is checked into the repo under some resources dir
e
Pants aside, developer to developer, I'd strongly (re) consider just having tests set up their own hermetic git repos unless there is some really pressing reason this won't work.
➕ 2
It sounds mildly terrifying to have tests operating on your project git repo.
➕ 1
s
oh trust me…. i didnt write these and i do not like these tests…. something i inherited. we do not setup any repos… we use git for diffs in sub proceseses in some of our clis.
Open in Slack
PreviousNext
Powered by