https://pantsbuild.org/ logo
Join Slack
Powered by
Hey, Pants gurus, I need help :slightly_smiling_fa...
# general
a
Hey, Pants gurus, I need help šŸ™‚ I need to run shell command (like 
coverage combine && coverage xml
to join coverage data files from different GitHub action workers) within 
venv
created by Pants (I saw no `test`/`pytest`/`coverage-py` names in cache folder but hashes). Is there any way to invoke this command in a Pants-way?
h
Hi, welcome! Double checking if you saw https://www.pantsbuild.org/docs/python-test-goal#coverage? Pants can run coverage for you and run those exact commands
h
Ah but pants combined coverage across processes on a single run, not across sharded runs
But I think it wouldn't be hard to add that, since Pants already knows how to download and install the coverage tool, and how to invoke it with the right args
It would be a bit of refactoring and then I guess adding a custom goal
@aloof-tent-90836 how would you be fetching these coverage files off the various worker machines?
There is an open question on how to model all this. Pants is normally used to working on files in the repo. These are files on other machines. So we need to figure out how the best way to model this. For example, do these files get downloaded by some process outside of Pants? Or are they are well-known urls that Pants can reference? Do we throw them all in a local directory and then just tell pants to merge everything in that dir?
The work here will be more about figuring that out, the actual implementation would be straightforward, and we can guide you through it
šŸ™Œ 1
a
@happy-kitchen-89482 I've managed to split test workload across machines using GitHub Actions and "matrix" feature, this job have steps rename 
.coverage
with hash suffixes (to be distinctive) and upload artefacts using actions/upload-artifact@v3 and having dedicated job actions/download-artifact@v3 further (the main trick is not providing any args - then all coverage files will be merged in the same destination). Pants cache is also shared between jobs within the same workflow. So, I've combined coverage result in this command sequence: ā€¢ coverage combine ā€¢ coverage report` ā€¢ coverage xml (to be compatible to push data to SonarCloud, probably, "push results" feature would be a nice addition to 
coverage-py
) But, in orded to be compatible, I've manually pin the coverage version and it can be eventually out of sync because now we have two places to lock dependencies. It would be nice to have some ability to reuse the same coverage executable that was used in testing stage. P.S. feel free to ask the same again if things above did not provide answers to you šŸ™‚
h
Thanks, that is helpful! A further question is, where do you want to run this merging? On some GitHub Actions job that depends on those other jobs it sounds like? And it downloads them via GHA artifacts?
I think I have a sense of what this should look like then
Something like a custom 
merge-coverage
goal that you pass paths that are not targets.
@hundreds-father-404 do we now have the ability to interpret CLI args as file paths that are not wrapped by targets, and may not even be in the repo?
a
On some GitHub Actions job that depends on those other jobs it sounds like? And it downloads them via GHA artifacts?
Yes, correct.
Something like a custom 
merge-coverage
goal that you pass paths that are not targets.
Thank you, I will look into. Would be helpful if you have can provide any link to the guide.
s
Reviving this a little bit: 1. IMO, pants shouldn't be responsible for moving files across the network. Thats a slippery slope and files could be stored anywhere 2. Pants should (by default) name coverage files by test shard index (i.e. 
coverage_0.xml
) 3. 
coverage-py
could add a goal i.e. 
merge-coverage
which merges all 
*.xml
files in 
[coverage-py].output_dir
6 Views
Open in Slack
PreviousNext
Powered by