Repository navigation
Stop the lockfile workflow from committing version-only churn - #1671
Merged
Merged
Conversation
Port PennLINC/qsirecon#416. pixi lock rewrites the workspace package's hatch-vcs version on every run, so the update job could push a version-only lockfile commit that retriggers itself. Skip the push when only the version, sha256 and editable lines changed, and skip the update when the head commit is from nipreps[bot].
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ports PennLINC/qsirecon#416.
Changes proposed in this pull request
The
update-lockfilejob in.github/workflows/pixi-lock.ymlcan loop on same-repo pull requests.pixi lock --checkexits 0 and prints "Lockfile up to date", but it still rewritespixi.lockwith the workspace package's hatch-vcs version (26.x.y.devN+g<sha>), which changes with every commit.datalad runthen commits the rewritten file, the bot's push triggers a newpull_requestrun, and the cycle repeats. This happened on PennLINC/qsirecon#396 after the switch frompull_request_targettopull_request(#1640 here). XCP-D's workflow is identical to qsirecon's, so it has the same problem; it hasn't shown up yet only because no PR has touchedpyproject.tomlorpixi.locksince the switch.This PR copies the two guards from the qsirecon PR without changes:
git diff --exit-code -I '^ (version|sha256|editable): ' <head-sha> HEAD -- pixi.lock. If those are the only lines that differ, the push is skipped and the job still succeeds. A real dependency change also touches the- pypi:/- conda:URL lines orrequires_dist, so it is still pushed.git log -1 --format=%anreportsnipreps[bot], the job setsrun_lockfile_update=false, so a run triggered by the bot's push never pushes again.I checked the regex against XCP-D's own
pixi.lockhistory (the last 13 commits that touched it, using git 2.50). The two version-only commits (6852d23 and 2f84879, which changed only theversion:/sha256:lines of thepypi: ./entries) exit 0 and would be skipped. The 11 real dependency changes (including the dependabot ruff bump 0d5ecdc, whose only dependency change was onerequires_distline) exit 1 and would be pushed.The datalad run command, the fork-only
validate-lockfilejob and thecheck-lockfilegate are unchanged.pyproject.tomlandpixi.lockare not touched.Documentation that should be reviewed
None.
Use of LLM tools
Required: check exactly one option. A CI check fails until exactly one box is checked.
Required: check the below if and only if you are a human. Contributions from bot accounts will not be accepted.
A CI check fails if this box is not checked.
🤖 Generated with Claude Code