You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Root cause: the last step (stefanzweifel/git-auto-commit-action) pushes an unsigned commit directly to main. The quality-and-security-gating repository ruleset (added after this workflow was originally written) now rejects that push:
remote: - 2 of 2 required status checks are expected.
remote: - Commits must have verified signatures.
Replaces the direct push with: commit on a throwaway branch → open a PR → gh pr merge --auto. GitHub's own merge-via-API produces a Verified commit, and auto-merge waits for the required CI checks to pass — no third-party action needed (uses the pre-installed git/gh CLIs already on the runner).
Removing git-auto-commit-action also drops its Node 20 runtime deprecation warning that showed up in the log (Node 20 is being deprecated...).
Fixes the versions.json generation logic: the new major version entry is now tagged (latest), and that suffix is stripped from the previously-latest entry (before this fix, the old entry kept (latest) forever and the new one never got it — the version dropdown would have shown the wrong "latest" label).
Manually applies the missed v2 (latest) entry to docs/public/versions.json, since the earlier failed run never got to commit it (the gh-pages branch snapshot for /v2/ was already stored successfully before the failure, so no rebuild is needed there).
Removes the now-unused stefanzweifel/git-auto-commit-action row from .github/skills/github-actions.md's action version reference table.
How did you verify your code works?
bun test (1024 passing), bun run lint, bun run format:check, bun run knip all green.
bun run docs:build succeeds; confirmed the built homepage now shows v2 (latest) in the version dropdown (previously would have shown plain v2 with v1 (latest) still listed).
Verified the jq expression for the (latest) relabeling locally against the actual versions.json shape.
Verified via git ls-tree origin/gh-pages that the /v2/ snapshot was already stored correctly by the partially-successful earlier run.
…tection
The 'Snapshot versioned docs' job (triggered by the v2.0.0 tag) failed at
its last step: stefanzweifel/git-auto-commit-action pushed an unsigned
commit directly to main, which the quality-and-security-gating ruleset
now rejects (2 required status checks expected + commits must be signed).
- Replace the direct push with a PR + gh pr merge --auto flow using the
pre-installed git/gh CLIs (no third-party action) — GitHub's own
merge-via-API produces a Verified commit, and auto-merge waits for the
required CI checks to pass before merging.
- Removing that action also drops its Node 20 runtime deprecation warning.
- Fix versions.json generation: the new major version entry is now tagged
'(latest)' and that suffix is stripped from superseded entries (was
previously left on the old entry, and never added to the new one).
- Manually apply the v2 entry to docs/public/versions.json, since the
earlier failed run never got to commit it.
- Remove the now-unused git-auto-commit-action row from
.github/skills/github-actions.md's action version table.
This PR changes versioned-docs publishing to use a branch and auto-merged PR, while fixing version labeling and removing the unused auto-commit action.
Changes:
Replaces direct pushes with branch/PR automation.
Marks the newest version as (latest) and adds v2.
Removes obsolete action documentation.
File
Description
docs/public/versions.json
Adds the v2 version entry.
.github/workflows/docs.yaml
Implements PR-based snapshot metadata publishing and latest-label handling.
Address Copilot review: gh pr merge --auto alone would wait indefinitely,
since the PR is opened using the default GITHUB_TOKEN and GITHUB_TOKEN-
authored events don't trigger new workflow runs — ci.yaml's pull_request
trigger never fires for this PR, so its required checks stay 'expected'
forever.
- Add workflow_dispatch to ci.yaml (exempt from the no-cascade
restriction, the documented way to get a fresh run from automation).
- docs.yaml: explicitly dispatch ci.yaml for the snapshot-metadata branch,
wait for it to complete (gh run watch --exit-status), then merge
directly instead of relying on --auto.
- Add the actions: write permission needed to dispatch workflows.
After rebasing onto origin/main, the metadata may already be present—for example, when rerunning this tag after the manually applied v2 entry or after a prior successful metadata merge. The staged-diff check above happened before the rebase, so git commit then exits with "nothing to commit" and fails the snapshot job. Re-check the staged diff after this git add and exit successfully when there is nothing left to publish.
Address Copilot review: the run lookup only filtered by branch name, so a
retry (or a stale run left over from an earlier attempt reusing this
branch) could match an older, already-green run whose SHA no longer
corresponds to what was just pushed — gh run watch would then report
success while the current commit's required checks stay unsatisfied.
Capture the pushed SHA right after the force-push and filter the
workflow_dispatch run list by headSha before watching it.
GITHUB_TOKEN merge does not trigger Docs deployment
.github/workflows/docs.yaml:336
This merge is performed with GH_TOKEN: ${{ github.token }}, so the resulting push to main is a GITHUB_TOKEN-authored event and will not start the push-triggered Docs workflow. Consequently, the merged snapshot metadata will not be deployed to Pages until an unrelated push or manual dispatch; explicitly dispatch docs.yaml for main after the merge (or use a non-GITHUB_TOKEN credential).
Address Copilot review: gh CLI's --jq flag takes a single expression
string and does not support jq's --arg the way the standalone jq binary
does. As written, --jq consumed "--arg" as its expression and the
remaining tokens were passed as unexpected extra arguments, erroring out
every time — meaning every future major-release snapshot job would fail
before reaching the merge step.
Interpolate the validated SHA (git rev-parse HEAD output, not user input)
directly into the jq expression string instead.
Handle empty staged diff after rebasing before committing
.github/workflows/docs.yaml:307
After rebasing the stash onto origin/main, the generated metadata may already be present (for example on a retry after the manually applied v2 entry). The pre-rebase staged-diff guard no longer covers that state, so git commit exits with “nothing to commit” and fails the snapshot job. Re-check the staged diff after this git add and exit successfully when there is nothing left to publish.
Dispatch Docs workflow after GITHUB_TOKEN-authored main merge
.github/workflows/docs.yaml:339
This merge still authenticates as ${{ github.token }}, so the resulting push to main is a GITHUB_TOKEN-authored event and will not trigger the push-based Docs workflow. The metadata can merge successfully while Pages remains on the previous artifact; explicitly dispatch docs.yaml for main after the merge, and update the comments that currently claim the push re-triggers deployment.
Address Copilot review findings:
- Handle empty staged diff after rebasing before committing: origin/main
may already carry the exact metadata being generated (e.g. a retry after
it was applied manually, as happened for v2.0.0), so the post-rebase
'git add' can have nothing staged. Re-check and exit successfully
instead of letting 'git commit' fail with nothing to commit.
- Dispatch Docs workflow after the GITHUB_TOKEN-authored main merge: that
merge is itself GITHUB_TOKEN-authored (via the API), so it does not
trigger docs.yaml's own push trigger — the deploy job would never pick
up the new snapshot automatically. Explicitly dispatch docs.yaml for
main right after merging, and correct the comments that previously
claimed the push re-triggers deployment.
Normalize existing target version entries on retries
.github/workflows/docs.yaml:208
The idempotent branch returns the file unchanged whenever the target /vX/ entry already exists, so a retry against metadata produced by the previous logic (for example, v2 present while v1 (latest) remains) never applies this relabeling fix. Normalize an existing target when it is the current version, while preserving a newer first entry for out-of-order reruns.
Align PR description with actual merge and CI strategy
.github/workflows/docs.yaml:353
The PR description says this flow uses gh pr merge --auto, but the implementation waits for a manually dispatched CI run and calls gh pr merge --squash directly. Please update the description to match the actual event/check strategy so the migration behavior is not misleading.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes the "Snapshot versioned docs" job failure on the
v2.0.0tag push: https://github.com/fulll/github-code-search/actions/runs/35442520334/job/105895704576Root cause: the last step (
stefanzweifel/git-auto-commit-action) pushes an unsigned commit directly tomain. Thequality-and-security-gatingrepository ruleset (added after this workflow was originally written) now rejects that push:gh pr merge --auto. GitHub's own merge-via-API produces a Verified commit, and auto-merge waits for the required CI checks to pass — no third-party action needed (uses the pre-installedgit/ghCLIs already on the runner).git-auto-commit-actionalso drops its Node 20 runtime deprecation warning that showed up in the log (Node 20 is being deprecated...).versions.jsongeneration logic: the new major version entry is now tagged(latest), and that suffix is stripped from the previously-latest entry (before this fix, the old entry kept(latest)forever and the new one never got it — the version dropdown would have shown the wrong "latest" label).v2 (latest)entry todocs/public/versions.json, since the earlier failed run never got to commit it (thegh-pagesbranch snapshot for/v2/was already stored successfully before the failure, so no rebuild is needed there).stefanzweifel/git-auto-commit-actionrow from.github/skills/github-actions.md's action version reference table.How did you verify your code works?
bun test(1024 passing),bun run lint,bun run format:check,bun run knipall green.bun run docs:buildsucceeds; confirmed the built homepage now showsv2 (latest)in the version dropdown (previously would have shown plainv2withv1 (latest)still listed).(latest)relabeling locally against the actualversions.jsonshape.git ls-tree origin/gh-pagesthat the/v2/snapshot was already stored correctly by the partially-successful earlier run.