vyos-documentation.git/.github, branch 1.5

ci: T8966: remove orphaned docs T-ID override (strict rule retired centrally) (#2084)

2026-06-06T07:02:45+00:00

T8960: ai-validation — mint vyos-bot token via get-token@production

2026-06-03T00:57:16+00:00

Swap the cross-repo-checkout token from the dedicated vyos-docs-reviewer App (VYOS_APP_ID/_PRIVATE_KEY) to the shared vyos-bot App via the fleet get-token composite, scoped contents:read. Skip-check now gates on APP_CLIENT_ID + APP_PRIVATE_KEY + ANTHROPIC_API_KEY (org-level vyos-bot creds); reword the stale token comment. PR-comment posting still uses the default GITHUB_TOKEN. Byte-identical to the paired reference copy in VyOS-Networks/vyos-docs-opus-reviewer (scripts/ai-validation.yml). 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit 459109f13adf026d012c4e803f4a86a8f84e6ce3)

ci(ai-validation): allow Pass 2 review on external-contributor PRs

2026-05-29T09:20:41+00:00

The upstream `anthropics/claude-code-action` performs a write-permission check on `github.actor` before our skip logic runs. On `pull_request_target` the actor is the PR author; external contributors resolve to `read` and the action exits 1 with `Actor does not have write permissions to the repository`. Net effect: AI validation has been failing on every external-contributor PR (LiudmylaNad, teslazonda, scottlaird in the last 4 weeks) while succeeding on maintainer PRs. Failure reproduced on run 26541079685 (PR #2061). Fix: set `allowed_non_write_users: '*'` on the Pass 2 step. The action bypasses the actor check when this input is set and `github_token` is provided (already the case). The action also auto-scrubs Anthropic / cloud / GHA secrets from subprocess envs when this input is set. Safe in THIS workflow because the existing defense-in-depth bounds what Pass 2 can do with untrusted PR content: - `allowedTools` restricted to inline-comment + read-only surfaces - `github_token` is the PR-scoped default (not the broader VYOS_APP_ID) - prompt marks PR content as untrusted via `` - workspace-wipe removes `CLAUDE.md` / `.claude/` before Pass 2 - prepare bundles MD via `git show HEAD:` (blob, not `cp`) Full rationale inlined as a comment block above the new input. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit 1fa39bd7ac64898f7a21922bc0f195d115d3cdeb)

ci(ai-validation): skip prepare on Mergify-authored PRs

2026-05-14T06:45:06+00:00

Lifts the existing Mergify-author short-circuit (today inside validate's `secrets-check` step) to a job-level `if:` on `prepare`, so the whole pipeline skips for backport/queue PRs. Why now: every Mergify backport whose merge ref shares no shallow ancestor with the (advanced) base branch fails the prepare step at git diff "$BASE...HEAD" --name-only ... fatal: FETCH_HEAD...HEAD: no merge base (because base is `git fetch --no-tags --depth=1` and the merge ref is `fetch-depth: 2`). Proximate symptom: run 25842928620 on PR #2042 (sagitta backport of #2023). AI Validation isn't a required check so the queue isn't blocked, but every Mergify backport is left with a red "prepare" check that adds noise to PR review. The validate-level skip in commit 0e8a2956 was correct for the "claude-code-action rejects bot-initiated runs" failure mode but fires too late — prepare has already run and crashed before validate's `if: needs.prepare.outputs.has_md_changes == 'true'` even evaluates. Implementation: single job-level `if:` on prepare. validate's `needs: [prepare]` cascades the skip naturally (skipped needs make the dependent's expression-based `if:` evaluate against empty outputs). The in-step author check in validate stays as defense-in-depth. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit 7d94d6116be1a4776b7317cb5190a83dd065e571)

ci(lint-doc): pin all GitHub Actions to commit SHAs

2026-05-14T05:08:38+00:00

Each `uses:` line was pinned to a mutable version tag (`@v6`, `@v0.8.4`, …). Tags can be rewritten to point to malicious code — CVE-2025-30066 (reviewdog/action-setup) and the tj-actions/changed-files incident in 2025 are the canonical real-world examples. GitHub's hardening guide for Actions recommends pinning to full-length commit SHAs and keeping the tag as a trailing comment for human readability. Resolved each action's tag to its commit SHA via `gh api /repos//git/refs/tags/` and verified the SHA is a commit (not an annotated-tag object) via `gh api /repos//git/commits/`: - actions/checkout v6 -> de0fac2e4500dabe0009e67214ff5f5447ce83dd - bullfrogsec/bullfrog v0.8.4 -> 1831f79cce8ad602eef14d2163873f27081ebfb3 - trilom/file-changes-action v1.2.4 -> a6ca26c14274c33b15e6499323aac178af06ad4b - actions/setup-python v6 -> a309ff8b426b58ec0e2a45f0f869d46889d02405 This change covers `lint-doc.yml` only. A fleet-wide sweep across every workflow in `.github/workflows/` is a separate effort — worth doing because the drift / supply-chain risk is the same in every one. Tracked as a follow-up to this PR's review. Tracked as item 11 of the rolling-side cleanup backlog from PR #2014 / #2019 / #2020 reviews. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit e99182b911dbe9d3a3f02e000426f7075cadc608)

ci(doc-linter): lint added + renamed files, not only modified

2026-05-14T05:08:38+00:00

Previous workflow: env: FILES_MODIFIED: ${{ steps.file_changes.outputs.files_modified }} run: python scripts/doc-linter.py "$FILES_MODIFIED" `trilom/file-changes-action`'s `files_modified` output is modifications-only. A PR adding a new `.md`/`.rst` doc page passed `files_added`, never `files_modified`, so a brand-new page with long lines or real public IPs slipped past the linter entirely. Workflow: also pass `files_added` and `files_renamed` as separate positional args. Each output is a JSON array (action v1.2.4) and is passed via env to avoid shell-quoting issues. Linter: `main()` now accepts one OR multiple positional argv entries, each a JSON array of paths. Arrays are merged and deduplicated before linting. Single-arg invocations remain backward-compatible. Switched from `ast.literal_eval` to `json.loads` — the action's outputs are JSON, and `json.loads` is the right tool (and dodges literal_eval-via-`eval`-substring linter warnings). Test coverage: - Two JSON arrays merge -> single linter run on union. - Empty-string argv entry skipped (no `files_renamed` in many PRs). - Malformed JSON -> falls back to walking DOCS_ROOT. - No argv -> walks DOCS_ROOT. - Single-arg invocation -> backward-compat preserved. Tracked as item 7 of the rolling-side cleanup backlog from PR #2014 / #2019 / #2020 reviews. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit 1ef5684729646ca3a24aff83ab8edd0aa57914c7)

ci(workflows): remove conflict markers from update-version-tags.yml

2026-05-14T00:12:04+00:00

`.github/workflows/update-version-tags.yml` has carried literal git conflict markers in its YAML header since the Mergify auto-backport in #1988 (cherry-pick of #1984 onto circinus) — the cherry-pick conflicted, but Mergify's `ignore_conflicts: true` default at the time committed the markers verbatim into the file. (The central Mergify config switched to `ignore_conflicts: false` a few days later as a direct response to this class of incident; #1988 had already merged.) Result: GitHub's YAML parser fails on `<<<<<<<` / `=======` / `>>>>>>>` and the workflow can't schedule any job. Every push to circinus touching `docs/**` or `context7.json` since #1988 merged reported "this run likely failed because of a workflow file issue" with 0 jobs. The downstream `context7-refresh.yml` (which uses `workflow_run` to react to this workflow's name) also never fired, so Context7's `1.5` index has been getting stale on every doc push. Fix: replace the file with rolling's verbatim content. The post-conflict-marker content on circinus was already byte-identical to rolling; only the marker block + the obsolete comment block above it differ. Confirmed with `diff <(git show origin/rolling:.../update-version-tags.yml) <(...)` returning empty after stripping markers. After this merges: - `Update version tags` runs on every docs-affecting push to circinus, moves the `1.5` tag to HEAD. - `Context7 refresh` fires via `workflow_run` and refreshes the `1.5` index. 🤖 Generated by [robots](https://vyos.io)

ci(ai-validation): skip validation on Mergify-authored PRs

2026-05-13T22:22:47+00:00

The upstream anthropics/claude-code-action rejects bot-initiated workflow runs with: Workflow initiated by non-human actor: mergify (type: Bot). Add bot to allowed_bots list or use '*' to allow all bots. This leaves a failing required check on every Mergify backport PR (#2025 today is the proximate symptom — circinus backport of #2016 is blocked from auto-merging by this). Per org policy, Mergify-authored PRs skip the bot-review flow entirely: the underlying change was already reviewed on the source PR. Re-running validation on the backport would also post duplicate findings. Fix: extend the existing `secrets-check` step (kept the id for backwards compat with the cascade of `if: steps.secrets-check.outputs.skip != 'true'` gates) to also short-circuit when `github.event.pull_request.user.login` equals `mergify[bot]`. Add a `skip_reason` output so the notify-on-PR step can distinguish bot-skip (silent) from missing-secrets (post a notice comment). Implementation notes: - PR author is bound through env: PR_AUTHOR (same pattern as secret bindings) so the template-expansion happens before bash sees the value as an already-quoted env variable. - Uses `printf '...%s\n' "$PR_AUTHOR"` for the notice line so the shell — not the YAML template engine — interpolates the author into the workflow log output. - Renamed step name to "Decide whether to skip validation" to reflect the broader scope; step id stays `secrets-check`. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit d75de0c24b971a2d87e817ac3cb8e09cb816aac0)

ci: inline doc-linter on circinus to match rolling

2026-05-13T21:12:32+00:00

The lint workflow on this branch referenced `vyos/.github/.github/workflows/lint-doc.yml@current`, which no longer exists in `vyos/.github` — `lint-doc.yml` was dropped from the central workflow set during the move toward repo-local linters. The reusable-workflow `uses:` line has been silently failing (no `doc-lint` check on recent circinus PRs). Mirror rolling's approach (inlined 2026-05-10): - Add `scripts/doc-linter.py` in this repo. Sourced from PR #2014's HEAD on rolling (the version that includes the `is_docs_path()` docs/-only scope guard so repo-root meta files like AGENTS.md and README.md are out of scope, plus the realpath / narrow-exception / Ruff fixes from that PR's review pass). - Replace `.github/workflows/lint-doc.yml` with an in-repo workflow that runs `python scripts/doc-linter.py "$FILES_MODIFIED"` against the changed-file list from `trilom/file-changes-action`. Same job shape as rolling. - Update the `## Lint` and `## CI` bullets in AGENTS.md to point at the in-repo paths. This restores actual lint coverage on circinus PRs and keeps the toolchain identical across rolling / circinus / sagitta. Behavior on the 11 remaining `.rst` pages is unchanged — the linter's SUPPORTED_EXTS already covers `.md`, `.rst`, and `.txt`. 🤖 Generated by [robots](https://vyos.io)

ci(mergify): fix T-ID-override rule name to match central baseline

2026-05-13T20:22:07+00:00

The override shipped in 3d44fe06 used rule names `Flag PR title not matching T-ID format` + `Flag commit message not matching T-ID format`. Per Mergify `extends:` semantics, same-name rules in the child REPLACE the parent's — and the central baseline in vyos/mergify uses a single rule named `Flag T-ID format violation in PR title or commit messages`. Different names → no replacement → parent rule keeps firing. Symptom (surfaced on PR #2014, title `docs(readme): …`): every PR without a `T:` token gets `invalid-title` labeled. Fix: collapse to one rule, rename to match the parent exactly. The condition (`closed AND -closed`) still never matches, so `toggle` removes the label on every evaluation — picks up any stale `invalid-title` from the broken-override window. The parent rule does not toggle `invalid-commit-title`; the second child rule for that label was extraneous and is dropped. 🤖 Generated by [robots](https://vyos.io) (cherry picked from commit ee2942a39e11b8d7996ba2f7f3ac53545300d647)