My project structure looks like this, . |--.git ├── build │ └── docker │ ├── BUILD │ └── Dockerfile ├── dist ├── pants.toml └── src └── repo-stats ├── BUILD ├── init.py └── repo_stats.py what I am trying achieve is execture

repo_stats.py --generate-stats

to collect repository metrics by git command and save them to a file

metrics.json

in next steps, package the

metrics.json

in the docker image. So far there is

docker_image

target

repostats-service

defined in

build->docker->BUILD

and

python_source

repo_stats

exists in

src/repo-stats->BUILD

I tried two methods 1. run

pants run src/repo-stats:repo_stats --export

to generate the json file and save to

/dist

, which generates the correct json content, then run

pants package build/docker:repostats-service

to include the json, whoever not able to address the correct json path during

repostats-service

build time by modifying

context_root

. 2. Create an

adhoc_tool

target in

src/repo-stats->BUILD

to generate the json and the

docker_image

depends on it, then run

pant package

do all the work. However, the

adhoc_tool

target not able to generate correct metrics because it runs within the sandbox, repository files not visiable to it. Any suggestion to either methods to make it works? thank you!!

Hm, having a command that needs to depend on the "invisible"

.git

files is a bit tricky. I think https://github.com/pantsbuild/pants/pull/20772 might be a relevant PR, which potentially allows running things in the workspace, rather than sandbox. This might then unblock the

adhoc_tool

approach. In the short term, you could try: • making sure the file exists, even just as an empty file that gets overwritten. One hack to do this would be putting a

touch path/to/file.json

into

.pants.bootstrap

https://www.pantsbuild.org/2.20/docs/using-pants/key-concepts/options#pantsbootstrap-file • define a custom plugin that does this, where you get more control over sandboxing etc. ◦ https://github.com/pantsbuild/pants/blob/0d35991d0814fa4f45ce504933d143525898e653/src/python/pants/backend/python/util_rules/vcs_versioning.py is a plugin that does something similar to power https://www.pantsbuild.org/2.20/reference/targets/vcs_version / https://www.pantsbuild.org/2.20/docs/using-pants/generating-version-tags-from-git ◦ https://www.pantsbuild.org/2.20/docs/writing-plugins/overview is the general docs for plugins • change your code (to, for instance, reduce how much information you need so that it either works with

vcs_version

as is, or, by setting an

GIT_COMMIT=$(git rev-parse head)

env var in

.pants.bootstrap

, or similar) None of those are particularly great.

Ha, running within the workspace is exact what I’m expected, it definite helps for similar case which heavily depends on contents in the repo.