[ci] Run PR checks on release branches - #441
Draft
Glitchy-Sheep wants to merge 1 commit into
Draft
Conversation
Signed-off-by: Roman Berezkin <roman.berezkin@flant.com>
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.
Problem
PRs into release branches get no CI. The only check they receive is DCO, an external GitHub App.
The trigger filter in
.github/workflows/release.yamlmatches the base branch of a PR:A PR into
release-0.32has a base that is notmain, so the workflow never starts.test,lintandpr-buildare all skipped.This matters because we ship from release branches. Tags are cut here, and the
releasejob builds artifacts from those tags. Backports land by hand, which is the kind of change that most needs checks. Today a broken backport shows up only when the tag is built.Fix
Add
release-*to the filter.The jobs need no changes. They already exist in this branch and match the ones on
main:ubuntu:22.04containerv2.11.4task test,task lint:check,task build:dist:allWhy this lands in the release branch
For
pull_requestevents GitHub reads the workflow from the merge ref of the PR, not from the default branch. The same change onmainwould not affect PRs that targetrelease-0.32.Worth making on
mainas well, so future release branches are cut with the filter already correct.Proof
This PR runs its own checks. GitHub built the merge ref from this branch, so the new filter already applied:
Testpass, 2m25sLintpass, 3m20sBuild for PRpass, 3m55sreleaseskipped, as its tag guard expectsNot in this PR
lintkeepscontinue-on-error: true, so it still cannot block a merge.Three PRs merged into this branch while lint never ran (#407, #413, #414), so a backlog of violations was possible. The run above shows there is none. Dropping the flag is safe, but it belongs in its own PR.
Note for open PRs
Open PRs will not pick these checks up on their own. Merging into the base branch recomputes the merge ref but emits no new
pull_requestevent. They need a push to the PR branch, or a close and reopen.