ci(docs): rename build job to docs-link-check for unique status context#181
Merged
Conversation
The docs link-check job was named `build`, which is the bare context GitHub Actions reports on the check-run. That's ambiguous repo-wide: any future workflow with a `build:` job would also satisfy a required status check matched by `build`. The required-status-check rule on `main` (jackin-project/jackin-github-terraform#11) lists this context explicitly, so we want it unique enough that only the docs link-check ever satisfies it. Rename the job from `build` to `docs-link-check`, which is unique across the repo's workflows. Also update the deploy job's `needs:` reference and the one prose mention in the docs-markdown-linting roadmap doc. The matching terraform PR jackin-project/jackin-github-terraform#11 lists both `build` and `docs-link-check` during the rename window, so this PR can merge without deadlocking against the still-live `Docs / build` → unmatched rule. After this merges and the terraform follow-up applies, only `docs-link-check` will be required. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
6 tasks
donbeave
added a commit
to jackin-project/jackin-github-terraform
that referenced
this pull request
Apr 25, 2026
…ck (#12) Replace the dual-context list ["build", "docs-link-check"] from #11 with ["docs-link-check"] only. The dual-context attempt was based on a wrong assumption that the required_status_checks list is OR-semantics (any one must pass). It's AND-semantics (every entry must pass). After #11 applied: - jackin-project/jackin#180 has Docs/build green, no docs-link-check check on its branch -> blocked, missing docs-link-check. - jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check green, no build check on its branch -> blocked, missing build. Each PR can only ever produce one of the two names, so AND-semantics makes the rule unsatisfiable. The fix: drop the legacy "build" context, since the rename PR (#181) will produce only "docs-link-check" once merged. Apply order: 1. Apply this PR. 2. #181 unblocks (it has docs-link-check green) -> merge it. Main now produces docs-link-check on every push. 3. Sync #180 with main (rebase or merge from main into the PR branch) so its CI run also produces docs-link-check -> #180 unblocks -> merge it. No admin override, no enforcement-disabled window, no bypass_actors weakening. The rule simply hops to its target context and existing PRs adapt naturally on rebase. Verified locally: - `tofu fmt -check` clean - `tofu validate` clean (pre-existing vulnerability_alerts deprecation warning unrelated) - Pre-commit secret scan clean Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Claude <noreply@anthropic.com>
donbeave
added a commit
that referenced
this pull request
May 6, 2026
…xt (#181) The docs link-check job was named `build`, which is the bare context GitHub Actions reports on the check-run. That's ambiguous repo-wide: any future workflow with a `build:` job would also satisfy a required status check matched by `build`. The required-status-check rule on `main` (jackin-project/jackin-github-terraform#11) lists this context explicitly, so we want it unique enough that only the docs link-check ever satisfies it. Rename the job from `build` to `docs-link-check`, which is unique across the repo's workflows. Also update the deploy job's `needs:` reference and the one prose mention in the docs-markdown-linting roadmap doc. The matching terraform PR jackin-project/jackin-github-terraform#11 lists both `build` and `docs-link-check` during the rename window, so this PR can merge without deadlocking against the still-live `Docs / build` → unmatched rule. After this merges and the terraform follow-up applies, only `docs-link-check` will be required. Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Claude <noreply@anthropic.com>
donbeave
added a commit
that referenced
this pull request
May 7, 2026
…xt (#181) The docs link-check job was named `build`, which is the bare context GitHub Actions reports on the check-run. That's ambiguous repo-wide: any future workflow with a `build:` job would also satisfy a required status check matched by `build`. The required-status-check rule on `main` (jackin-project/jackin-github-terraform#11) lists this context explicitly, so we want it unique enough that only the docs link-check ever satisfies it. Rename the job from `build` to `docs-link-check`, which is unique across the repo's workflows. Also update the deploy job's `needs:` reference and the one prose mention in the docs-markdown-linting roadmap doc. The matching terraform PR jackin-project/jackin-github-terraform#11 lists both `build` and `docs-link-check` during the rename window, so this PR can merge without deadlocking against the still-live `Docs / build` → unmatched rule. After this merges and the terraform follow-up applies, only `docs-link-check` will be required. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Codex <codex@openai.com>
donbeave
added a commit
that referenced
this pull request
May 7, 2026
…xt (#181) The docs link-check job was named `build`, which is the bare context GitHub Actions reports on the check-run. That's ambiguous repo-wide: any future workflow with a `build:` job would also satisfy a required status check matched by `build`. The required-status-check rule on `main` (jackin-project/jackin-github-terraform#11) lists this context explicitly, so we want it unique enough that only the docs link-check ever satisfies it. Rename the job from `build` to `docs-link-check`, which is unique across the repo's workflows. Also update the deploy job's `needs:` reference and the one prose mention in the docs-markdown-linting roadmap doc. The matching terraform PR jackin-project/jackin-github-terraform#11 lists both `build` and `docs-link-check` during the rename window, so this PR can merge without deadlocking against the still-live `Docs / build` → unmatched rule. After this merges and the terraform follow-up applies, only `docs-link-check` will be required. Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Claude <noreply@anthropic.com>
donbeave
added a commit
that referenced
this pull request
May 7, 2026
…xt (#181) The docs link-check job was named `build`, which is the bare context GitHub Actions reports on the check-run. That's ambiguous repo-wide: any future workflow with a `build:` job would also satisfy a required status check matched by `build`. The required-status-check rule on `main` (jackin-project/jackin-github-terraform#11) lists this context explicitly, so we want it unique enough that only the docs link-check ever satisfies it. Rename the job from `build` to `docs-link-check`, which is unique across the repo's workflows. Also update the deploy job's `needs:` reference and the one prose mention in the docs-markdown-linting roadmap doc. The matching terraform PR jackin-project/jackin-github-terraform#11 lists both `build` and `docs-link-check` during the rename window, so this PR can merge without deadlocking against the still-live `Docs / build` → unmatched rule. After this merges and the terraform follow-up applies, only `docs-link-check` will be required. Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Claude <noreply@anthropic.com>
donbeave
added a commit
to jackin-project/jackin-github-terraform
that referenced
this pull request
May 7, 2026
…ck (#12) Replace the dual-context list ["build", "docs-link-check"] from #11 with ["docs-link-check"] only. The dual-context attempt was based on a wrong assumption that the required_status_checks list is OR-semantics (any one must pass). It's AND-semantics (every entry must pass). After #11 applied: - jackin-project/jackin#180 has Docs/build green, no docs-link-check check on its branch -> blocked, missing docs-link-check. - jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check green, no build check on its branch -> blocked, missing build. Each PR can only ever produce one of the two names, so AND-semantics makes the rule unsatisfiable. The fix: drop the legacy "build" context, since the rename PR (#181) will produce only "docs-link-check" once merged. Apply order: 1. Apply this PR. 2. #181 unblocks (it has docs-link-check green) -> merge it. Main now produces docs-link-check on every push. 3. Sync #180 with main (rebase or merge from main into the PR branch) so its CI run also produces docs-link-check -> #180 unblocks -> merge it. No admin override, no enforcement-disabled window, no bypass_actors weakening. The rule simply hops to its target context and existing PRs adapt naturally on rebase. Verified locally: - `tofu fmt -check` clean - `tofu validate` clean (pre-existing vulnerability_alerts deprecation warning unrelated) - Pre-commit secret scan clean Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com> Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Rename the docs link-check job from `build` to `docs-link-check` so it has a unique check-run name across the repo's workflows.
Why
When jackin-project/jackin-github-terraform#10 added a required-status-check rule for the docs gate, the rule context was `"Docs / build"` — the workflow/job display name shown in the GitHub PR UI. But GitHub matches required checks against the bare check-run `name`, which for this job is just `"build"` (verified in #180's run). The mismatch silently turned every PR's `mergeStateStatus` to `BLOCKED`.
The fix has to land in two places:
What changes
That's it. No behavior change in CI itself — same steps, same env, same lychee version. Only the name of the check that GitHub Actions reports differs.
Sequencing (important)
This PR depends on jackin-project/jackin-github-terraform#11 having been applied before merge. That PR lists `["build", "docs-link-check"]` as the required contexts during the transition, so this PR's renamed `docs-link-check` check-run satisfies the rule.
If the terraform apply hasn't happened yet, this PR will be blocked by the live `"Docs / build"` requirement (which will never match again after this rename) — so wait for the apply.
After this merges, a follow-up terraform apply drops `"build"` from the list, leaving `["docs-link-check"]`.
Test plan
🤖 Generated with Claude Code