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.
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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
ff66eccis dated 2026-02-21, six months before that commit existed, and shows a nativego buildwith 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:make checkcannot 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 checkcan be served from the Docker layer cache on a byte-identical tree. This commit adds a new file, soCOPY . .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.
Pull request closed