fix(ci): run the Go workflow on pull_request - #246
Merged
Conversation
The workflow triggered on `push` only. A contributor without push access forks, pushes to their fork, and opens a PR — the push event fires in their repo, so the Build/Lint/Test runs attach there and never reach the PR here. With those contexts required and no bypass actors since #243, such a PR is permanently unmergeable. No fork PR has ever been opened against this repo, so this has not fired; it is now a hard block rather than a soft one, which is what makes it worth closing. `push` is narrowed to develop rather than left bare alongside the new trigger. A same-repo PR matches both events, so an unscoped `push` would run the whole suite twice per PR and surface each required context twice — the ambiguity that makes required checks unreliable. One run per event now: PRs via `pull_request`, develop keeps its post-merge run. Trade-off: pushing a feature branch no longer runs CI until a PR exists. The ruleset requires a PR for every change, so nothing reaches develop unchecked. The workflow references no secrets, so it runs correctly under the read-only token a fork PR receives. > *This was generated by AI*
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.
Closes #245.
.github/workflows/go.ymltriggered onpushonly. A contributor without push access forks, pushes to their fork, and opens a PR — the push event fires in their repo, so theBuild/Lint/Testruns attach to the fork and never reach the PR here. Since #243 made those contexts required with no bypass actors, such a PR would be permanently unmergeable.No fork PR has ever been opened against this repo (last 100 are all
7Cav-owned branches), so this has never fired. It is now a hard block rather than a soft one, which is what makes it worth closing.Why
pushis narrowed rather than left aloneAppending
pull_requestto the existingon: [push]would be the obvious change and the wrong one: a same-repo PR matches both events, so the whole suite would run twice per PR and each required context would appear twice — exactly the ambiguity that makes required status checks unreliable.Scoping
pushtodevelopgives one run per event:developTrade-off worth naming: pushing a feature branch no longer runs CI until a PR exists. The ruleset requires a PR for every change, so nothing reaches
developunchecked — but you will see CI slightly later in the loop than before.The workflow references no secrets (checkout,
go mod tidy,go build,make lint,go testagainst a MariaDB service container), so it runs correctly under the read-only token a fork PR receives. Service containers are available to fork PRs.Self-verifying
This PR is itself the test: if the
pull_requesttrigger works,Build/Lint/Testappear below from apull_requestrun rather than a push run. What it cannot prove is the fork path specifically — that needs an actual fork PR.