Repository navigation
ci: pull the corpus's images in parallel and print per-test durations - #533
Conversation
6b6ec2d to
ce7bb94
Compare
16b9f5d to
14cd8c0
Compare
darkclad
left a comment
darkclad
left a comment
There was a problem hiding this comment.
Reviewed the two commits above #534 (791e5c2a, 14cd8c0a), which change only run_workflows.yml. Giving test_cwl_docker_extract the pytest workers looks safe. It writes to the same autogenerated/ tree that test_run_workflows_on_push already writes to under those workers, and the Docker daemon dedupes concurrent pulls of one image. --durations=0 on both corpus steps is what the description asks for.
No Run Workflows dispatch for this branch has run yet, though. All three (02:12, 05:25 and 06:02 UTC) sat queued with no steps executed and were then cancelled by a later dispatch. The concurrency group, ${{ github.workflow }}-cwltool-${{ github.ref }}-${{ inputs.sender_repo }}-${{ inputs.mm-workflows_ref}}, does not include inputs.wic_ref. github.ref is always master for a dispatched run, so every sophios branch dispatched from vjaganat90/sophios against mm-workflows main shares one group: this PR, #534 and the nf323 rebase each cancel the others. That problem predates this PR. Its effect here is that the 2.2-min serial baseline has no parallel measurement to compare with, and nothing yet shows the parallel pull passing on the runner. Could you add inputs.wic_ref to the group (here or in a follow-up) and link a completed run, so this change has a passing run behind it?
| run: | | ||
| nproc | ||
| free -g | head -2 | ||
| df -h / | tail -1 |
There was a problem hiding this comment.
Nit: the comment above says this reports the disk the corpus runs on, but / is only that disk if the runner's work directory sits on the root filesystem. On a self-hosted runner it may be a separate mount. df -h "$GITHUB_WORKSPACE" | tail -1 measures the disk the corpus actually uses.
There was a problem hiding this comment.
Fixed in d5f4513: the step now prints df -h "$GITHUB_WORKSPACE" /tmp. The corpus's outputs and cache sit in the workspace and cwltool's scratch goes to /tmp, so either can be the one that fills up.
14cd8c0 to
a0c365d
Compare
|
A finished run of this branch on my fork: run 38690046521 at |
a0c365d to
d5f4513
Compare
test_cwl_docker_extract compiles each on-push workflow and docker-pulls its images; the step ran its 30 tests in series for 2.2 min (run 38441960443), nearly all of it waiting on the registry. The runs that follow already share the autogenerated/ directory across PYTEST_WORKERS processes, so the pull step does the same.
The corpus steps print pytest's slowest-durations table, as the weekly lane does, so the longest workflows under cwltool are read from the log instead of inferred from toil. A step before setup prints the core count the worker count is sized against, memory, and how full the workspace and /tmp disks are.
d5f4513 to
248cae0
Compare
darkclad
left a comment
darkclad
left a comment
There was a problem hiding this comment.
LGTM. The runner step now reports the workspace and /tmp disks. Fork run 38690046521 shows cwl-docker-extract taking 35 s with the workers, down from 2.2 min. Its only failures are the three bbbc downloads, and those pass once paired with image-workflows#28. Adding inputs.wic_ref to the concurrency group is still worth a follow-up, so dispatches from different sophios branches stop cancelling each other.
2 participants
Stacked on #534 (
fix/vjaganat90-images). Merge that first; this PR's own changes are the commits above it.What
Why The image pull took 2.2 min in series, almost all of it waiting on the registry, and the slowest workflows were read off toil's timings rather than measured under cwltool.