From b465e3b1185189305e3c668d77b9f1ef939a097c Mon Sep 17 00:00:00 2001 From: Yuriy Andamasov Date: Mon, 11 May 2026 02:35:05 +0300 Subject: ci(ai-validation): revert DB-download tag pin to latest:true MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CRITICAL REGRESSION fix. PR #1969 changed the reference-DB download from `latest: true` to `tag: ${{ env.REVIEWER_REF }}` (set to `reviewer-v1.0.1`). Verification post-merge showed that: - The `reviewer-v1.0.1` tag exists but has **no GitHub release** attached: $ gh api /repos/VyOS-Networks/vyos-docs-opus-reviewer/releases/tags/reviewer-v1.0.1 {"message": "Not Found", "status": "404"} - Reference DBs are published to a separate release stream by the matrixed `rebuild-reference` workflow, tagged `ref-db-` (e.g. `ref-db-20260510-193946`). The reviewer Python package and the reference DBs have independent release cadences. `robinraju/release-downloader` with `tag: reviewer-v1.0.1` therefore 404s. The download step has `continue-on-error: true` so the run proceeds, but the fail-closed gate at "Fail if reference DB missing while MyST files are in the diff" then errors every validate run on a PR with MD changes. Our own recent test PRs (#1947 / #1956 / #1957 / #1968 / #1969 / #1970 on rolling, plus the circinus/sagitta backports) all happened to be infrastructure-only — `has_md_changes` was `false`, validate was skipped at the job level, and the DB step was never invoked. The regression was therefore invisible until the next real `.md`-changing PR would have failed red. Reverting to `latest: true` is the correct behavior. The reference DB schema is intentionally backwards-compatible across reviewer Python releases; the freshest DB is always usable. If the schema ever changes incompatibly, the way to opt out is bump `REVIEWER_REF` and the new reviewer code will refuse to load an older DB at the fail-closed gate — _exactly_ what we have today, just one level up. A paired PR on VyOS-Networks/vyos-docs-opus-reviewer/scripts/ ai-validation.yml ([#15](https://github.com/VyOS-Networks/vyos-docs-opus-reviewer/pull/15)) applies the same revert + bumps REVIEWER_REF default to v1.0.2 so canonical and deployed stay aligned after the next reviewer tag. A separate companion PR will backport this revert to circinus and sagitta to keep the workflow file byte-identical across all three release branches. --- .github/workflows/ai-validation.yml | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/.github/workflows/ai-validation.yml b/.github/workflows/ai-validation.yml index d5f1160f..c19f7737 100644 --- a/.github/workflows/ai-validation.yml +++ b/.github/workflows/ai-validation.yml @@ -323,11 +323,17 @@ jobs: uses: robinraju/release-downloader@28fc21f50d76778e7023361aa1f863e717d3d56f # v1.13 with: repository: VyOS-Networks/vyos-docs-opus-reviewer - # Pin the DB to the same release tag as REVIEWER_REF so a future - # reviewer-v1.x.x release with a schema change cannot be silently - # picked up while the pinned reviewer code still expects the old - # schema. Reproducibility > recency for this artifact. - tag: ${{ env.REVIEWER_REF }} + # latest: true is correct here. Reference DBs live in their own + # `ref-db-` release stream produced by the matrixed + # rebuild-reference workflow — NOT attached to the `reviewer-v1.x.x` + # release that REVIEWER_REF pins. A `tag: ${{ env.REVIEWER_REF }}` + # form would 404 (the reviewer-v1.x.x tag has no GH release with + # DB assets). The reference DB schema is intentionally backwards + # compatible across reviewer Python releases; the freshest DB is + # the right choice. If the DB schema ever changes incompatibly, + # bump REVIEWER_REF in the consuming workflow and the new code + # will refuse to load an older-format DB at the fail-closed gate. + latest: true fileName: reference-db-${{ steps.branch.outputs.vyos1x }}.tar.gz out-file-path: .reference-db token: ${{ steps.app.outputs.token }} -- cgit v1.2.3