ci: scope docs-only skipping to jobs, so required checks still report - #1955
Merged
Conversation
Replaces the trigger-level paths-ignore from #1949 and #1950. That approach was wrong and it blocked #1953 from merging. What was wrong. GitHub documents the distinction I got backwards: a workflow skipped by path filtering leaves its checks in a pending state that never arrives, and a pull request requiring those checks can never merge. A JOB skipped by an if: conditional reports Success and does not block. So the filtering has to live on the jobs, not on the trigger. I compounded that by asserting master had no required checks, "verified: the branch protection endpoint returns 404". That verification was invalid. The 404 means the token cannot read protection details, not that none exist; the branch reports protected=true, and #1953 was refused with "the base branch policy prohibits the merge". What this does. A "Change scope" job computes whether anything outside docs/, *.md and LICENSE changed, and go-test, e2e-test, build-and-publish and release-artifacts are gated on it. Documentation-only pull requests skip those jobs, which report Success, so they still merge. Only pull requests are scoped. A push or a dispatch always runs the full pipeline. That is deliberate: release-fast-path.yml re-tags :edge to :vX.Y.Z only when the :edge revision label matches the tagged commit, so a master commit without an image breaks tagging. That is exactly what happened to the v3.10.0 tag, where the tagged commit was documentation-only. Master pushes now always produce an image, at the cost of running the pipeline on documentation commits to master. Pull requests are where the queue pressure was. Two conservative defaults in the scope check: a non-pull_request event and an empty diff both count as code, so an unexpected shape runs everything rather than silently skipping. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PQS3XLoPD98yu9pxdRujqg
The previous commit left two 'if:' keys on release-artifacts, one pre-existing tag guard and one added by the gating pass. GitHub rejects a duplicate mapping key and refuses to load the whole workflow, which is why the branch push produced a run named after the file path with zero jobs, and why PR #1954 got no run at all. PyYAML accepts duplicates silently (last wins), so local validation passed. The two conditions are now one expression, and the check I run locally looks for duplicate keys per job as well as valid YAML. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PQS3XLoPD98yu9pxdRujqg
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
1 participant
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.
Same change as #1954, opened from a branch on this repository instead of from a fork. #1954 never received a workflow run: zero runs and zero check suites for its head commit, and closing and reopening it changed nothing. A manual
workflow_dispatchon master ran immediately, so Actions itself is working; thepull_requestevent from the fork is what produces nothing. See the note at the end.Replaces the trigger-level
paths-ignorefrom #1949 and #1950. That approach was wrong, and it is currently blocking #1953 from merging.What was wrong
GitHub documents the distinction I had backwards:
So the filtering has to live on the jobs, not on the trigger.
I compounded it by claiming, in both the commit and the description of #1949, that master had no required checks: "verified: the branch protection endpoint returns 404". That verification was invalid. A 404 there means the token cannot read protection details, not that none exist. The branch reports
protected=true, and #1953 was refused withthe base branch policy prohibits the merge.What this does
A
🔎 Change scopejob computes whether anything outsidedocs/,*.mdandLICENSEchanged.go-test,e2e-test,build-and-publishandrelease-artifactsare gated on its output. A documentation-only pull request skips those jobs, they report Success, and the PR can merge.Only pull requests are scoped. A push or a dispatch always runs the full pipeline.
That second part is deliberate and it fixes a separate failure.
release-fast-path.ymlre-tags:edgeto:vX.Y.Zonly when the:edgerevision label matches the tagged commit. A master commit with no image breaks tagging, which is what happened to the v3.10.0 tag: the tagged commit was documentation-only, the fast path could not re-tag, it fell back to a dispatch, and the dispatch published nothing (#1951). Master pushes now always produce an image. The cost is running the pipeline on documentation commits to master; pull requests are where the queue pressure was.Two conservative defaults in the scope check: a non-
pull_requestevent and an empty diff both count as code, so an unexpected shape runs everything rather than silently skipping.Note for whoever has repository settings access
Fork pull requests stopped getting workflow runs between 22:36 and 05:40. #1949, #1950 and #1951 all came from the same fork and each got a run; #1954 got none, with no check suite created at all, which is different from a skipped run.
repos/.../actions/permissionsreturns 403 for a non-admin token, so this could not be confirmed from the API. If the "Fork pull request workflows from outside collaborators" setting was tightened, that would explain it, and it would affect every outside contributor, not just this branch.