docs(gitea): a skipped job reports SUCCESS, not pending #3

2026-09-29T06:08:40Z

gitea-admin commented

2026-09-29 06:08:40 +00:00

The runner came up and the first CI jobs this repo has ever run went green — which
falsified a claim merged in #2.

Measured, PR #1 and PR #2:

Context	Result	Time
`gate / gate (pull_request)`	success	1m58s / 1m34s
`gate / gate (push)`	success	1m32s
`gate / conformance (pull_request)`	success — "Has been skipped"	—

#2 said requiring the conformance context would deadlock every PR, since the job is
if: false and never runs. That is wrong. Gitea reports a skipped job as success.
Requiring it would not deadlock — it would pass vacuously, forever, while nothing ran.

The conclusion is unchanged (never require it) but the reason inverts, and the corrected
reason matters more: under HARD RULE 4, a permanently-green check that verifies nothing
is worse than a deadlock. A deadlock is loud.

Also records that (push) contexts appear only for branches matching gate.yml's push
trigger — feature/**, fix/**, docs/**, chore/**, and not feat/**. That is
why PR #1's feat/ branch produced only pull_request contexts. Require
gate / gate (pull_request) alone.

CLAUDE.md's enforcement table now reflects that the runner half is fixed and observed
green while branch protection is not, plus a warning that a green tick is not by itself
evidence anything ran.

Gate: ./ci/gate.sh — PASS, rc 0, 74s.

Co-Authored-By: Claude Opus 5 (1M context) [email protected]

🤖 Generated with Claude Code

The runner came up and the first CI jobs this repo has ever run went green — which falsified a claim merged in #2. **Measured, PR #1 and PR #2:** | Context | Result | Time | |---|---|---| | `gate / gate (pull_request)` | success | 1m58s / 1m34s | | `gate / gate (push)` | success | 1m32s | | `gate / conformance (pull_request)` | **success — "Has been skipped"** | — | #2 said requiring the `conformance` context would deadlock every PR, since the job is `if: false` and never runs. **That is wrong.** Gitea reports a skipped job as `success`. Requiring it would not deadlock — it would pass *vacuously*, forever, while nothing ran. The conclusion is unchanged (never require it) but the reason inverts, and the corrected reason matters more: under HARD RULE 4, a permanently-green check that verifies nothing is worse than a deadlock. A deadlock is loud. Also records that `(push)` contexts appear only for branches matching `gate.yml`'s push trigger — `feature/**`, `fix/**`, `docs/**`, `chore/**`, and **not** `feat/**`. That is why PR #1's `feat/` branch produced only `pull_request` contexts. **Require `gate / gate (pull_request)` alone.** `CLAUDE.md`'s enforcement table now reflects that the runner half is fixed and observed green while branch protection is not, plus a warning that a green tick is not by itself evidence anything ran. Gate: `./ci/gate.sh` — **PASS, rc 0, 74s**. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea-admin added 1 commit 2026-09-29 06:08:40 +00:00

docs(gitea): a skipped job reports SUCCESS, not pending -- correct the deadlock claim

gate / gate (push) Successful in 1m33s

Details

gate / gate (pull_request) Successful in 1m32s

Details

gate / conformance (push) Has been skipped

Details

gate / conformance (pull_request) Has been skipped

Details

234cc6a71a

The runner came up on 2026-09-29 and the first CI jobs this repo has ever run went
green, which falsified a claim merged in #2.

MEASURED:
  gate / gate (pull_request)          success   1m58s (PR 1), 1m34s (PR 2)
  gate / gate (push)                  success   1m32s (PR 2 only)
  gate / conformance (pull_request)   success   "Has been skipped"

#2 said listing the conformance context as a required check would deadlock every PR,
because the job is `if: false` and never runs. That is wrong. Gitea reports a skipped
job as SUCCESS. Requiring it would not deadlock anything -- it would pass VACUOUSLY,
forever, while nothing ran.

The conclusion is unchanged (never require it) but the reason inverts, and the corrected
reason matters more: under HARD RULE 4 a permanently-green check that verifies nothing is
worse than a deadlock. A deadlock is loud. This is the exact fail-open shape the
2026-09-18 audit and this one both keep finding.

Also records that the (push) contexts only appear for branches matching gate.yml's push
trigger -- feature/**, fix/**, docs/**, chore/** -- and NOT feat/**, which is why PR 1's
feat/ branch produced only pull_request contexts. Require the pull_request context alone,
or PRs from non-matching prefixes never satisfy the rule.

CLAUDE.md's enforcement table is updated: the runner half is genuinely fixed and observed
green, the branch-protection half is not. Adds the warning that a green tick is not by
itself evidence that anything ran.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

jakman85 merged commit e9f441b5ce into main

2026-09-29 06:12:31 +00:00

jakman85 referenced this issue from a commit

2026-09-29 06:12:32 +00:00

Merge pull request 'docs(gitea): a skipped job reports SUCCESS, not pending' (#3) from fix/conformance-context-is-fail-open into main

gitea-admin referenced this pull request

2026-09-30 17:45:19 +00:00

fix(auth): five oauth2-proxy sidecars shared one cookie, died at 5 minutes, and served no metrics #28

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Home-Network/home-network-k3s-impl#3