fix(build): skip a bake whose head is already contained in main

gitea_admin commented

2026-08-14 09:57:01 +00:00

Contributor

Cutting a branch through the API/UI pushes the BRANCH POINT, so the sensor started a second 25-minute kernel bake of an already-released commit — and because the operator projects builds onto the PipelineBuild keyed by sha, the RELEASED build record (linux-build-22875a8f484a) was re-opened to Running with no workflow.

Guard tests git containment (main is release-only, so a contained head is built+released+immutable) rather than the build record, which the operator re-opens the instant the workflow starts. Fail-closed; force=true overrides.

submit-lint caught that {{workflow.parameters.force}} would be rejected at submit on the release path (it would have broken every kernel release); param-injection caught pasting params into a token-mounting script body. Both fixed. 130/130 guards green, new contract test has a negative control.

Cutting a branch through the API/UI pushes the BRANCH POINT, so the sensor started a second 25-minute kernel bake of an already-released commit — and because the operator projects builds onto the PipelineBuild keyed by sha, the RELEASED build record (linux-build-22875a8f484a) was re-opened to Running with no workflow. Guard tests git containment (main is release-only, so a contained head is built+released+immutable) rather than the build record, which the operator re-opens the instant the workflow starts. Fail-closed; force=true overrides. submit-lint caught that {{workflow.parameters.force}} would be rejected at submit on the release path (it would have broken every kernel release); param-injection caught pasting params into a token-mounting script body. Both fixed. 130/130 guards green, new contract test has a negative control.

gitea_admin added 1 commit

2026-08-14 09:57:01 +00:00

fix(build): skip a bake whose head is already contained in main

pipeline/ci CI green @ 2b6b780144b0

Details

2b6b780144

Creating a branch through the Forgejo API or web UI emits a push whose
`after` is the BRANCH POINT, not new work. The CI sensor cannot tell that
apart from a real commit, so cutting fix/input-evdev off main today started
a second 25-minute kernel bake of 22875a8f -- a commit already built and
released as v6.18.44-seanfarm31.

The waste was the smaller half. The operator projects a build workflow onto
the PipelineBuild keyed by its sha, so the rebuild RE-OPENED the released
build's record: linux-build-22875a8f484a went to Running with an empty
workflow name. Had it failed, the record behind a shipped release would
read Failed.

The guard tests git containment, not the build record. main is release-only
fleet-wide, so a head contained in main is built, released and immutable.
The record cannot answer this question: the operator re-opens it the instant
the workflow starts, so every step sees Running and never Succeeded.

Fail-closed throughout -- an API error, an unparseable answer or an
unresolved sha builds. force=true overrides for a deliberate cache bust.

Two guards shaped this and are worth recording:
- submit-lint refused {{workflow.parameters.force}}: the release path submits
  these templates in a workflow that declares no such parameter, and an
  unresolvable reference is rejected AT SUBMIT. It would have broken every
  kernel release. force is now an input with a default at both levels.
- param-injection refused pasting parameters into a script body that mounts
  the Forgejo token; they travel in env: instead, which kubelet sets verbatim.

The matrix outputs gained defaults so a skipped bake leaves them resolvable.

sean added 1 commit

2026-08-14 11:02:58 +00:00

fix(build): bound the Tekton log follow so a finished bake cannot park

pipeline/ci CI green @ f05bd7fd762d

Details

f05bd7fd76

poll() follows the build pod's log with an unbounded `kubectl logs -f`.
The stream never closes once the pod completes, so the loop never returns
to the BuildRun status check at the top of the iteration, and 2>/dev/null
hides that nothing is happening.

Measured today: BuildRun linux-kernel-ci-g9szq reached Succeeded at
10:26:15Z; its bake step was still Running 35 minutes later, holding the
kernel-bake mutex the entire time (so every other kernel build queued behind
a build that was already done). It completed within seconds of killing the
parked kubectl by hand.

Same defect the deploy template fixed in 106d8452, where every kubectl now
carries a timeout. The follow now ends at the cap, the loop re-checks the
BuildRun, and a build that is genuinely still running is simply followed
again on the next pass.

pipeline-bot merged commit f05bd7fd76 into trunk

2026-08-14 12:05:40 +00:00

Rows
Columns

fix(build): skip a bake whose head is already contained in main #2043