| Age | Commit message (Collapse) | Author |
|---|
|
* T9208: add scutum to docs CI branch enumerations
The scutum docs branch (VyOS 1.6 train) was cut from circinus on
2026-08-13. Register it in the branch enumerations that gate CI on the
default branch:
- context7-refresh.yml: add scutum to the push-trigger branch list, the
workflow_dispatch choice options and the defence-in-depth variant
allow-list, so a docs push on scutum refreshes its own Context7
variant instead of being dropped.
- context7.json: add a `scutum` entry to `previousVersions`. Context7
registers branch variants from this file on the default branch; a
refresh with `branch: "scutum"` 404s until that registration exists.
Enumerations only — no behaviour change for the existing rolling,
circinus and sagitta variants.
🤖 Generated by [robots](https://vyos.io)
* T9208: add scutum to the context7 branch-to-version mapping rule
The previousVersions entry registers the scutum variant, but the
branch-to-version mapping rule Context7 feeds to the model still jumped
straight from rolling to circinus and claimed rolling covers "1.6+" —
the version scutum now serves. Add the scutum row and drop the stale
version claim from rolling so the rule matches the variant list.
Caught by adversarial review on 2b10f78.
|
|
* 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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
|
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)
|
