WIP: DO NOT MERGE: CI probe for #126 #127

clawbot · 2026-08-09T08:46:49+02:00

clawbot commented

2026-08-09 08:46:49 +02:00

Do not merge. Do not review. This will be closed and its branch deleted as soon as a CI result is recorded.

Diagnostic for #126, which reports that the job log Gitea returns for a commit does not correspond to that commit — the log for ff66ecc is dated 2026-02-21, six months before that commit existed, and shows a native go build with pre-#93 DNS skips that no longer exist in this codebase.

The Actions API returns 403 for this account, so the log cannot be read directly. This is a natural experiment instead, and it settles more than a log read could.

What this commit contains

A single new file, internal/config/zz_ci_probe_test.go, containing one deliberately failing test:

t.Fatal("CI-PROBE-126: planted failure; if CI reports success this gate did not run")

make check cannot pass on this tree.

What each outcome proves

If CI reports failure — the runner executes the real, current gate on real, current content. The symptom in #126 is then a log-association or API artefact, and the gate itself is sound. Benign.

If CI reports success — the four candidate explanations in #126 collapse to the worst one: a stale runner replaying an old job definition. Every green tick on this repo would then reflect a build nobody has inspected.

Why the layer-cache defect cannot confound this

#115 (fixed in PR #122, not yet merged) means RUN make check can be served from the Docker layer cache on a byte-identical tree. This commit adds a new file, so COPY . . invalidates and every layer below it must rebuild. A cached green is not available here — the check step has to run.

A useful secondary signal is duration: a fail-fast abort should be visibly shorter than a full green pass, which is further evidence the pipeline's internal structure is being exercised rather than a canned status returned.

Provenance

The approach was suggested by a manager on a sibling repo, which ran the equivalent experiment accidentally: a known-bad-lint commit went red in 1m2s and its fixed successor went green in 3m3s, twenty minutes apart on the same branch. That established content-sensitivity, contemporaneity, and structure-tracking durations in one stroke.

That result does not clear this repo — it narrows the problem to something repo- or runner-specific rather than a site-wide Gitea Actions defect, which makes a local cause more likely, not less.

**Do not merge. Do not review. This will be closed and its branch deleted as soon as a CI result is recorded.** Diagnostic for #126, which reports that the job log Gitea returns for a commit does not correspond to that commit — the log for `ff66ecc` is dated 2026-02-21, six months before that commit existed, and shows a native `go build` with pre-#93 DNS skips that no longer exist in this codebase. The Actions API returns 403 for this account, so the log cannot be read directly. This is a natural experiment instead, and it settles more than a log read could. ## What this commit contains A single new file, `internal/config/zz_ci_probe_test.go`, containing one deliberately failing test: ```go t.Fatal("CI-PROBE-126: planted failure; if CI reports success this gate did not run") ``` `make check` cannot pass on this tree. ## What each outcome proves **If CI reports failure** — the runner executes the real, current gate on real, current content. The symptom in #126 is then a log-association or API artefact, and the gate itself is sound. Benign. **If CI reports success** — the four candidate explanations in #126 collapse to the worst one: a stale runner replaying an old job definition. Every green tick on this repo would then reflect a build nobody has inspected. ## Why the layer-cache defect cannot confound this #115 (fixed in PR #122, not yet merged) means `RUN make check` can be served from the Docker layer cache on a **byte-identical** tree. This commit adds a new file, so `COPY . .` invalidates and every layer below it must rebuild. A cached green is not available here — the check step has to run. A useful secondary signal is duration: a fail-fast abort should be visibly shorter than a full green pass, which is further evidence the pipeline's internal structure is being exercised rather than a canned status returned. ## Provenance The approach was suggested by a manager on a sibling repo, which ran the equivalent experiment accidentally: a known-bad-lint commit went red in 1m2s and its fixed successor went green in 3m3s, twenty minutes apart on the same branch. That established content-sensitivity, contemporaneity, and structure-tracking durations in one stroke. That result does **not** clear this repo — it narrows the problem to something repo- or runner-specific rather than a site-wide Gitea Actions defect, which makes a local cause more likely, not less.

clawbot added 1 commit 2026-08-09 08:46:49 +02:00

test: deliberately failing probe to verify CI executes the gate

check / check (push) Failing after 23s

Details

4251e743cd

Throwaway branch for dnswatcher#126. Determines whether the CI runner
executes the current workflow or replays a stale job definition. Must
never be merged; branch is deleted after the result is recorded.

clawbot closed this pull request

2026-08-09 08:47:00 +02:00

clawbot referenced this pull request

2026-08-09 08:47:33 +02:00

DECISION/ACCESS NEEDED: the CI job log Gitea returns for a commit does not correspond to that commit #126