Review pipeline-tooling changes under the copy the pipeline actually runs, not the PR's own copy
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 66/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- devtools
Research direction
The issue names no file, so first find where the repository's review method is written down, and read how it currently treats diffs to CI or pipeline tooling. Add the rule that the reviewer states which copy of the tooling the real run executes and tests under that copy, with the lock-held example for any diff that re-invokes a lock-taking tool. Done when the review method contains this check with that example.
Written by the indexing model from the issue text.
Description
Problem. A PR that changes CI or pipeline tooling is usually verified with the PR's own copy of that tooling, but the pipeline often runs another copy: the base branch's pinned one. A change to a runner cannot fix the run that lands it, so a green self-check proves little.
Failure scenario. A pinned runner holds a non-reentrant file lock and calls a script the PR adds. That script re-invokes the runner, which waits on the same lock forever at 0% CPU until the run deadline. The PR's own precheck passed because it ran the PR's copy.
Proposed rule. For any diff touching pipeline tooling, state which copy the real run executes and test under that copy. If the diff spawns or re-invokes a lock-taking tool, test it with the lock held.
Done when. The review method lists this check with the lock-held example.
- Dominant language
- Python
- Stars
- 2
- Forks
- 1
- Avg merge
- 1h 27m
- Merged PRs (30d)
- 561
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from protocol/perun
-
Difficulty 4/5 3-5 days Newbie friendliness 18/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 22/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
protocol/perun#1779 · 1 comment ·
Maintainers usually reply within 1 day
-
area:delivery enhancement priority:medium
Difficulty 5/5 Over a week Newbie friendliness 35/100
protocol/perun#1592 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Paraxial.trace returns NaN for an object at infinity when the entrance pupil is at the first surfaceOpen
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement ios launcher
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Substrait consumer doesn't recognise `shift_left` / `shift_right` from functions_arithmetic.yamlOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/datafusion#27059 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
loteran/Arctis-Sound-Manager#368 ·
Maintainers usually reply within 1 day
-
feed submission
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
MobilityData/mobility-database-catalogs#1787 ·
Maintainers usually reply within 2 days