Skip to content

fix(ci): the palette gate turns main red after every release - #356

Merged
0xmanhnv merged 1 commit into
developfrom
fix/palette-gate-on-push
Aug 3, 2026
Merged

fix(ci): the palette gate turns main red after every release#356
0xmanhnv merged 1 commit into
developfrom
fix/palette-gate-on-push

Conversation

@0xmanhnv

@0xmanhnv 0xmanhnv commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

What happened

v0.4.0 merged to main and Quality Checks went red immediately — a wall of
palette violations, none of them from the release.

Why

The step runs on push as well as pull_request:

run: bash scripts/check-palette-drift.sh "origin/${{ github.base_ref || 'develop' }}"

On a push, github.base_ref is empty, so the expression falls back to
develop and the gate diffs main against develop.

Release merges are squashed, so main is not an ancestor of develop — its
HEAD has a single parent. The merge-base therefore lands before the last
release, and a month of already-gated code is reported as newly added.

I added a release-merge skip in ui#347 for base_ref == main. It cannot fire
here: on a push there is no base ref at all.

The fix

PR-only. The gate answers "what does this branch add"; after the merge those
lines are in the base, the question has no subject, and nobody can act on the
answer.

No coverage is lost — every one of those lines was gated on the PR that
introduced it, which is the entire design of a --new-from-rev style gate.

Why this is not the failure mode this repo keeps hitting

docker-scan gated on event_name == 'push' the scan never ran anywhere, and reported green
this change the check already ran where it is actionable; the second run is the one giving a false answer

Removing a run nobody can act on is not the same as removing the only run.

Verified on top of the committed change

Case Result
PR base origin/develop, clean branch exit 0
PR base origin/develop, violation committed exit 1
base origin/main (release merge) still skips

The gate answers 'what does this branch ADD', which only means something while
there is a branch to answer for. After the merge those lines are in the base,
so a push run re-asks a question nobody can act on.

Worse, it gets the wrong answer. On a push github.base_ref is empty, so the
expression falls back to develop and the gate diffs main against develop.
Release merges are squashed, so main is not an ancestor of develop, the
merge-base lands before the last release, and a month of already-gated code is
reported as newly added. That is what turned main red immediately after v0.4.0
merged, with a wall of violations none of which came from the release.

Now PR-only. That loses no coverage: every one of those lines was gated on the
PR that introduced it, which is the whole design of --new-from-rev style gates.

Not the docker-scan shape: that one was gated on event_name and therefore never
ran anywhere. Here the check has already run on the only event where it can be
acted upon, and the second run is the one producing a false answer.
@0xmanhnv
0xmanhnv merged commit dacca0e into develop Aug 3, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant