summaryrefslogtreecommitdiff
path: root/.github/workflows/context7-refresh.yml
AgeCommit message (Collapse)Author
12 daysci: track Context7 LTS variants by branch instead of moved git tags (#2127)Yuriy Andamasov
* ci: track Context7 LTS variants by branch instead of moved git tags Switch the Context7 1.5/1.4 variants from tag-backed to branch-backed: - context7.json: previousVersions entries `{tag:"1.5"}`/`{tag:"1.4"}` → `{branch:"circinus"}`/`{branch:"sagitta"}`. Context7 now indexes the LTS branch HEADs directly. - Delete update-version-tags.yml. Its sole purpose was force-moving the git tags 1.5/1.4 to circinus/sagitta HEAD so the tag-backed Context7 variants tracked the branches. With branch-backed variants Context7 tracks the HEAD natively, so the tag indirection — and its re-run "moves the tag backward" footgun — is gone. - context7-refresh.yml: trigger directly on push to rolling/circinus/ sagitta (docs/** + context7.json paths) instead of chaining off the deleted tag-mover via workflow_run; refresh payload uses `branch:"circinus"`/`branch:"sagitta"` for the non-default variants. Operator follow-up (post-merge): the circinus/sagitta branch variants must be registered in the Context7 dashboard (a refresh by branch 404s until Context7 crawls the new config), and the now-unused git tags 1.5/1.4 can be deleted. 🤖 Generated by [robots](https://vyos.io) * ci: harden jq repo interpolation in context7-refresh Adversarial review (agy): use the $GITHUB_REPOSITORY runner env var (mapped as REPO) instead of inlining ${{ github.repository }} into the jq command string, matching the safe env-mapping pattern already used for EVENT_NAME/REF_NAME. github.repository is validated and low-risk, but this structurally removes the interpolation-into-shell surface. 🤖 Generated by [robots](https://vyos.io)
2026-05-11ci(context7): gate version-tag move + refresh on docs-only changesYuriy Andamasov
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)
2026-05-11ci: sanitize concurrency.group against arbitrary variant inputYuriy Andamasov
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)
2026-05-11ci: validate workflow_dispatch variant input against allowlistYuriy Andamasov
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)
2026-05-11ci: address Context7 LTS variants via tag field, not branch fieldYuriy Andamasov
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: <name>' to 'tag: <name>'. - 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)
2026-05-11ci: fix Context7 refresh — branch-name addressing + default-variant handlingYuriy Andamasov
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)
2026-05-10ci: drop leading slash in Context7 libraryNameYuriy Andamasov
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)
2026-05-10ci: add connect-timeout and max-time to Context7 curl callYuriy Andamasov
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)
2026-05-10ci: add explicit API key presence check before curlYuriy Andamasov
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)
2026-05-10ci: add Context7 refresh workflowYuriy Andamasov
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)