vyos-documentation.git/.github/workflows/context7-refresh.yml, branch current

ci(context7): gate version-tag move + refresh on docs-only changes

2026-05-11T08:28:48+00:00

Add `paths:` filter to `Update version tags` push trigger so infra-only pushes (workflows, scripts, Docker, README, etc.) skip the tag move and therefore skip the downstream Context7 refresh. Context7 only ingests `docs/**` (per context7.json `folders`), so refreshing on infra commits wasted API calls and gave no benefit. `context7.json` is also covered because changes to its `rules`/`folders`/`excludeFolders` affect what Context7 returns even when no .md files moved. The version tag's only consumer is Context7, so skipping the move on infra-only pushes is semantically correct — the tag still represents the latest docs state. `workflow_dispatch` on context7-refresh.yml remains available to force a refresh out of band. 🤖 Generated by [robots](https://vyos.io)

ci: sanitize concurrency.group against arbitrary variant input

2026-05-10T22:58:23+00:00

CodeRabbit review on #1962 flagged that concurrency.group is evaluated at workflow scheduling time, BEFORE the shell-level allowlist case in the job runs. An API-triggered workflow_dispatch with arbitrary variant value (e.g. 'gh workflow run -f variant=foobar') would produce concurrency key 'context7-refresh-foobar' and bypass dedupe with legitimate runs. Gate inputs.variant in the expression against the same allowlist ('rolling'/'1.5'/'1.4'). Map head_branch values to their canonical variant names so the workflow_run path also resolves cleanly. Fall through to 'invalid' if neither path matches — the shell allowlist then fails the run loud. 🤖 Generated by [robots](https://vyos.io)

ci: validate workflow_dispatch variant input against allowlist

2026-05-10T22:02:47+00:00

Copilot review on #1962 flagged that the type:choice UI constraint on workflow_dispatch.inputs.variant is bypassable when invoked via API (gh workflow run -f variant=…). An empty or arbitrary value would: - Generate a malformed concurrency key (context7-refresh- with empty suffix, since inputs.variant || head_branch || '' both go falsy) - Pass garbage to Context7's API (404s gracefully, but still a wasted runner minute and noisy) Add an explicit allowlist case after VARIANT is computed. Fails loud with a clear message before any downstream call. 🤖 Generated by [robots](https://vyos.io)

ci: address Context7 LTS variants via tag field, not branch field

2026-05-10T21:57:18+00:00

Post-#1961, the rolling auto-refresh (default variant, no field) succeeds, but workflow_dispatch for branch=circinus/sagitta still 404s. Further empirical curls against the live API revealed: POST /api/v1/refresh {"libraryName":"/vyos/vyos-documentation","branch":"circinus"} → HTTP 404 {"error":"branch_not_found","message":"Branch 'circinus' not found"} POST /api/v1/refresh {"libraryName":"/vyos/vyos-documentation","tag":"1.5"} → HTTP 200 {"message":"Refresh started successfully"} So Context7's API addresses variants by their REGISTRATION TYPE on the dashboard: - default variant (rolling) → omit both 'branch' and 'tag' - tag-backed variants (1.5/1.4) → 'tag' field - branch-backed non-default → 'branch' field The dashboard shows 'rolling' with a branch icon and '1.5'/'1.4' with tag icons. The 'branch' field only addresses entries registered as branches; 'tag' addresses entries registered as tags. This is undocumented in the public GitHub Actions integration page but works against the live API. Changes: - Restore the variant mapping (circinus → 1.5, sagitta → 1.4) — that matches the actual dashboard variant names. #1961 had dropped this in favor of branch-name passthrough, which only worked for the default. - Switch the non-default payload from 'branch: ' to 'tag: '. - workflow_dispatch input renamed back from 'branch' to 'variant'; choices back to [rolling, '1.5', '1.4']. - Restore the variant-keyed concurrency expression (with rewrite chain). - Update the documentation comment to record the empirical API semantics. Spec: ~/.claude/specs/2026-05-10-context7-github-actions-integration-design.md 🤖 Generated by [robots](https://vyos.io)

ci: fix Context7 refresh — branch-name addressing + default-variant handling

2026-05-10T21:37:26+00:00

The post-merge auto-fired runs from #1948/#1949/#1950 all returned 4xx errors. Diagnostic curls against the live Context7 API revealed two issues: 1. The 'branch' parameter addresses variants by their underlying Git branch name (rolling/circinus/sagitta), not by their tag display name (rolling/1.5/1.4). Sending 'branch: "1.5"' returns: HTTP 404 {"error":"branch_not_found","message":"Branch '1.5' not found"} 2. The default variant refreshes when the 'branch' field is omitted entirely. Sending 'branch: "rolling"' returns: HTTP 400 {"error":"branch-not-found","message":"Failed to refresh library"} But omitting the field returns: HTTP 200 {"message":"Refresh started successfully"} 3. (Bonus, validating #1951 was wrong direction.) The libraryName must include the leading slash: 'libraryName: "/vyos/vyos-documentation"' per Context7's docs. Without the slash returns: HTTP 404 {"error":"library_not_found"} This commit restores the leading slash that #1951 incorrectly removed. Changes: - Restore leading slash on libraryName ('/' + github.repository). - Drop the tag-name mapping in the case statement; pass head_branch directly as the branch value. - Omit the 'branch' field when head_branch is 'rolling' (default variant). - workflow_dispatch input renamed from 'version' to 'branch'; choice options changed from [rolling, '1.5', '1.4'] to [rolling, circinus, sagitta]. - Simplified concurrency expression (no longer needs the rewrite chain). - Documentation comment updated to explain the branch-name addressing. Spec: ~/.claude/specs/2026-05-10-context7-github-actions-integration-design.md This is the 'fallback mapping' path that the spec's variant table already documented as a contingency — pre-flight confirmed it's the correct path. 🤖 Generated by [robots](https://vyos.io)

ci: drop leading slash in Context7 libraryName

2026-05-10T20:32:08+00:00

Context7's API expects the bare repo identifier 'vyos/vyos-documentation' (verified at https://context7.com/vyos/vyos-documentation), not the leading-slash form. The auto-fired workflow_run cycle after #1950 / #1948 / #1949 merged returned HTTP 404 on all three variants because of the extra slash. Spec: ~/.claude/specs/2026-05-10-context7-github-actions-integration-design.md (spec narrative referenced Codex's round-1 advice to use leading slash; that advice was empirically wrong against the live Context7 API). 🤖 Generated by [robots](https://vyos.io)

ci: add connect-timeout and max-time to Context7 curl call

2026-05-10T20:19:46+00:00

Without explicit timeouts, a stalled TCP handshake or slow server response blocks the workflow indefinitely. --connect-timeout 10 bounds the TCP/connect phase; --max-time 60 caps total request duration. Both are within reasonable limits for a refresh POST that normally completes in well under a second. 🤖 Generated by [robots](https://vyos.io)

ci: add explicit API key presence check before curl

2026-05-10T20:08:13+00:00

If CONTEXT7_API_KEY is unset or empty (e.g. secret not yet configured), emit a clear error message rather than letting curl fail with a generic auth error. The `:-` guard is needed because `set -u` would otherwise abort before the `-z` test when the variable is truly unset. 🤖 Generated by [robots](https://vyos.io)

ci: add Context7 refresh workflow

2026-05-10T20:00:03+00:00

Refreshes Context7's index of the VyOS documentation library on completion of 'Update version tags', mapping rolling/circinus/sagitta to Context7 variants rolling/1.5/1.4 respectively. Triggered via workflow_run because GITHUB_TOKEN-driven tag pushes from update-version-tags.yml do not fan out to downstream workflows. workflow_dispatch added for ad-hoc and bootstrap refreshes. Spec: ~/.claude/specs/2026-05-10-context7-github-actions-integration-design.md 🤖 Generated by [robots](https://vyos.io)