Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Automated docs augmentation failed. Run: https://github.com/stacklok/docs-website/actions/runs/24743776702 Retry via the |
Two fixes to get the Renovate-triggered skill runs actually working
and observable:
1. `allowed_bots: renovate` — without this, claude-code-action
refuses to run any workflow initiated by a bot identity with
"Workflow initiated by non-human actor: renovate (type: Bot)."
This is the action's default safety behavior. We deliberately
allow Renovate (the whole point of the pipeline) but leave the
list narrow — other bots still blocked.
2. `track_progress: true` + `display_report: true` — these expose
live progress during long skill runs:
- track_progress posts a sticky tracking comment on the PR that
updates as the skill works through each phase
- display_report surfaces the Claude Code Report in the Actions
Step Summary as the step runs, not just after completion
Skill runs that previously went silent for 20-45 min now stream
live status.
The track_progress change was supposed to ship in #757 but was
pushed after the squash-merge and got orphaned on the branch.
Seen on run 24743776702 — Renovate PR #759's workflow failed with
the bot-actor rejection.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
Two bugs from the first real Renovate run (#759) and its retry: 1. workflow_dispatch retry failed at "Resolve PR number and head ref" with "failed to run git: fatal: not a git repository". The step runs BEFORE actions/checkout, so `gh pr view` has no git context to infer the repo from. Added `--repo "$GITHUB_REPOSITORY"` to the three gh pr view calls that run pre-checkout (HEAD_REF + AUTHOR in the retry branch of step "pr", plus BASE in the retry branch of step "eff"). The error message we initially saw ("author ... is not an accepted bot") was just the shell source being echoed by `bash -x`-like output; the actual runtime never got to that point. 2. The refresh commit (~38 files, reference-asset regeneration) was only pushed at the END of the workflow, after the skill. When the skill failed or was cancelled — which it did repeatedly today — the refresh commit died with the runner and PRs ended up with only the one-line YAML bump. Now push the refresh commit as soon as it's created, so the reference-asset work lands on the PR branch independent of skill outcome. This was a pending commit that got orphaned by #760's squash-merge; re-shipping. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Claude finished @rdimitrov's task in 17m 54s —— View job Upstream release docs update for v0.23.1
What changedv0.23.0 / v0.23.1 documentation updates, source-verified against 1. All YAML examples in guides, integrations, tutorials, and MCP server guides now use 2. New v0.23.0 section in Documents the CRD API graduation: deprecation notice, zero-downtime upgrade path, and 3-step migration procedure. The change summary table now includes v0.23.0. 3. New "Callback URL for upstream providers" section in Documents that when 4. Cedar server-scoped policies: already correctly documented; PR #4965 was a bug fix that makes existing docs accurate. No doc changes needed. No gaps requiring human context - all changes had clear, verifiable documentation paths. |
…764) * Gitignore claude-code-action's .claude-pr/ scratch dir PR #759 got a bad "Add upstream-release-docs content for toolhive v0.23.1" commit carrying 17 files of leakage from .claude-pr/.claude/* + .claude-pr/CLAUDE.md + .claude-pr/.husky/. That directory is created by anthropics/claude-code-action@v1 as scratch workspace during skill runs — it clones our own .claude/ skill configs into a sibling dir for its own use. None of it belongs on the repo's main branch. Our workflow's "Commit and push" step runs `git add -A` after the skill, which scooped up the scratch dir alongside any legitimate content. Ignoring /.claude-pr at the root so it never gets staged. The legit content from the skill (guide updates, v1alpha1 → v1beta1 migration docs) lands as intended via claude-code-action's own auto-commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Switch skill to Opus and split generation from editorial review Two changes to the claude-code-action invocation: 1. Switch to Opus 4.7 via `claude_args: --model claude-opus-4-7`. Generation benefits from the stronger model on long multi-file edits and source verification, and docs-review benefits from the same quality. The default is Sonnet. 2. Split the single "multi-pass" skill step into two separate claude-code-action invocations: - `skill_gen`: runs /upstream-release-docs end-to-end (all 6 phases, including the skill's own internal docs-review in Phase 5). - `skill_review`: runs /docs-review over the files the previous commit changed, in a fresh context with no exposure to the generation session's internal reasoning. Dan's hypothesis: fresh context for the editorial pass tends to catch style and structure issues the generation pass rationalized away. This was previously a same-session Pass 2 after the skill. The removed Pass 3 (Phase 5 re-verification) was redundant with the skill's own Phase 5 and is dropped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
49b7bbd to
3098350
Compare
|
Claude finished @rdimitrov's task in 17m 17s —— View job Upstream release docs update for v0.23.1
Impact map
|
|
Claude finished @rdimitrov's task in 6m 9s —— View job Docs review for v0.23.1 release docs
SummaryReviewed the two files with substantive new prose ( Factual verification (all claims hold)
Edits applied
Not changed
|
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
6be1807 to
9ba0b5c
Compare
|
Claude finished @rdimitrov's task in 10m 11s —— View job Upstream release docs for v0.23.1 (re-run on PR reopen)
What changedBranch state note: only the Renovate bump ( 1. 2. New Covers the CRD API graduation (all 12 CRD kinds served at both versions, 3. New "Default callback URL for upstream providers" subsection in Documents that when 4. Cedar / authz docs: no changes. PR #4965 is a bug fix that makes the existing 5. Auto-generated reference ( Source verification (all claims)
GapsNo GAPS.md file created. Every feature's "why" and mechanics were resolvable from the release notes, PR descriptions, and source at the tag. Validation notes
|
Source-verified against stacklok/toolhive@v0.23.1.
- Bump apiVersion from v1alpha1 to v1beta1 across 40 guide,
integration, and tutorial MDX files. migrate-to-v1beta1.mdx
is excluded so historical "before" examples stay accurate.
- Add v0.23.0 section to migrate-to-v1beta1.mdx covering the
CRD API graduation, zero-downtime upgrade behavior, and
manifest migration steps.
- Add "Default callback URL for upstream providers" subsection
to auth-k8s.mdx documenting the {resourceUrl}/oauth/callback
default applied when redirectUri is omitted.
|
Claude finished @rdimitrov's task in 5m 26s —— View job Docs review for v0.23.1 release docs
SummaryReviewed the two files with substantive new prose in Factual verification (all claims hold)
Edits applied
Not changed
|
- migrate-to-v1beta1.mdx: replace the kubectl --raw API discovery command with a jq query over CRD status.storedVersions, which actually identifies CRDs still holding v1alpha1-stored resources (the previous command only listed kinds served at v1alpha1, always all of them). - auth-k8s.mdx: smooth out the awkward leading-ellipsis sentence in the "Default callback URL for upstream providers" section by merging it into the preceding sentence and dropping the parenthetical em-dash-like aside in favor of a natural "for example" clause. Co-authored-by: Radoslav Dimitrov <undefined@users.noreply.github.com>
Replaces the upfront `gh api repos/X/collaborators/Y` filter with per-user `gh pr edit --add-reviewer` attempts. Routes GitHub's own rejection (422) into the mention list instead of relying on our filter to pre-compute the split. Why: on PR #759 the collaborator check returned 404 for Stacklok employees who ARE collaborators via the `stackers` team (push permission on docs-website) -- `ChrisJBurns`, `jhrozek`, `reyortiz3`, `tgrunnagle`. Only `rdimitrov` passed, so four reviewers silently vanished. A local check with a PAT that has read:org confirms all five are collaborators; the discrepancy appears to be GITHUB_TOKEN treating team-based access differently at the collaborator endpoint, though we haven't pinned the exact rule. The authoritative answer is "will GitHub accept this person as a reviewer right now" -- asking that question directly (via the add-reviewer API) avoids the filter being wrong. Each attempt is independent, so one rejection doesn't kill the batch. The separate "Add reviewers" step is now redundant -- assignments happen inline during candidate iteration. Dropped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… paths (#776) * @-mention non-collaborator release contributors; widen toolhive docs paths Two independent but related improvements to the upstream-release-docs pipeline: 1. Reviewer routing: @-mention contributors we can't auto-assign The existing reviewer-extract step batched all non-bot release commit authors and filtered to docs-website collaborators. On PR #759 that filter silently dropped four of five candidates (`reyortiz3`, `ChrisJBurns`, `jhroz`, `tgrunnag` are all upstream toolhive contributors but not collaborators on docs-website). The filter is mandatory because `gh pr edit --add-reviewer` returns 422 for any non-collaborator in the list, dropping the valid reviewers alongside the invalid ones. Now split the candidates: - ASSIGN_LIST (collaborators): batch-assigned as reviewers via `--add-reviewer`. Unchanged behavior. - MENTION_LIST (everyone else): @-mentioned in a new "Release contributors" section of the PR body so they see the PR documenting their work even though we can't request their review via the API. Detecting Stacklok employees directly (e.g. via the `stackers` team) requires a PAT with read:org scope -- `GITHUB_TOKEN` doesn't have it, and public-org-membership checks only see members with public membership. Deferred; noted in a comment. 2. Expand toolhive docs_paths hints The `toolhive` upstream is a monorepo shipping the CLI, the Kubernetes operator, and the vMCP gateway, plus cross-cutting features that land in concepts/, integrations/, tutorials/, and hand-written reference pages. The previous hints listed only the three guides-* folders. In practice the skill's Phase 3 impact map expanded beyond the hints (PR #759 touched concepts/, integrations/, tutorials/), so this is a focus improvement rather than a bug fix -- more accurate hints let Phase 2's source reading home in on the right areas without re-scanning unrelated docs. Other projects' hints are already accurate for their scope. toolhive-cloud-ui intentionally keeps docs_paths: [] -- no associated docs in this repo yet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Assign reviewers per-user instead of pre-filtering by collaborator API Replaces the upfront `gh api repos/X/collaborators/Y` filter with per-user `gh pr edit --add-reviewer` attempts. Routes GitHub's own rejection (422) into the mention list instead of relying on our filter to pre-compute the split. Why: on PR #759 the collaborator check returned 404 for Stacklok employees who ARE collaborators via the `stackers` team (push permission on docs-website) -- `ChrisJBurns`, `jhrozek`, `reyortiz3`, `tgrunnagle`. Only `rdimitrov` passed, so four reviewers silently vanished. A local check with a PAT that has read:org confirms all five are collaborators; the discrepancy appears to be GITHUB_TOKEN treating team-based access differently at the collaborator endpoint, though we haven't pinned the exact rule. The authoritative answer is "will GitHub accept this person as a reviewer right now" -- asking that question directly (via the add-reviewer API) avoids the filter being wrong. Each attempt is independent, so one rejection doesn't kill the batch. The separate "Add reviewers" step is now redundant -- assignments happen inline during candidate iteration. Dropped. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Re-applies the documentation changes from PR #759 (reverted in 8406977) that cover the upstream toolhive v0.23.0 release: - Add v0.23.0 section to the v1beta1 migration guide covering the CRD API graduation from v1alpha1 to v1beta1. - Document the default callback URL for MCPExternalAuthConfig upstream providers in the Kubernetes auth guide. - Bump apiVersion to toolhive.stacklok.dev/v1beta1 across manifest examples in guides, integrations, and tutorials. Auto-generated CRD reference assets were already refreshed in 4ac41c0 and are not re-applied here.

This PR contains the following updates:
v0.22.0→v0.23.1After this PR opens,
.github/workflows/upstream-release-docs.ymladds source-verified content edits for the new release. Forstacklok/toolhive, the same workflow also syncs reference assets (CLI help, Swagger) and regenerates the CRD MDX pages.Release Notes
stacklok/toolhive (stacklok/toolhive)
v0.23.1Compare Source
What's Changed
Full Changelog: stacklok/toolhive@v0.23.0...v0.23.1
v0.23.0Compare Source
🚀 Toolhive v0.23.0 is live!
A milestone release: ToolHive's CRD API graduates from
v1alpha1tov1beta1, signaling API stability — with a zero-downtime upgrade path that keeps existingv1alpha1resources working untouched. Two targeted operator bug fixes round out the release.🔄 Deprecations
toolhive.stacklok.dev/v1alpha1deprecated in favour oftoolhive.stacklok.dev/v1beta1— will be removed in a future release (#4849). Both versions are served simultaneously; existing resources continue to work untouched.kubectlnow prints a deprecation warning on every access to av1alpha1resource — migrate manifests toapiVersion: toolhive.stacklok.dev/v1beta1at your own pace.Migration guide: CRD graduation to v1beta1
All 12 ToolHive CRD kinds (
MCPServer,MCPGroup,MCPRegistry,MCPRemoteProxy,MCPToolConfig,MCPExternalAuthConfig,VirtualMCPServer,VirtualMCPGroup,VirtualMCPCompositeToolDefinition, and their peers) are now served at bothv1alpha1andv1beta1. The schemas are identical — only the version string differs — so there is no data-format migration to perform.Who is affected: anyone with manifests pinned to
apiVersion: toolhive.stacklok.dev/v1alpha1.Before
After
Migration steps
v1alpha1resources survive the upgrade with unchanged Deployment UIDs.apiVersion: toolhive.stacklok.dev/v1beta1and re-apply them. Kubernetes stores the new version in etcd; the object'sstatus.storedVersionswill advance to includev1beta1.v1beta1, a future release will drop thev1alpha1entry from the CRDs. Migrate at your convenience before then.PR: #4849 — Closes #2556
🆕 New Features
toolhive.stacklok.dev/v1beta1as the storage version, withv1alpha1kept served-and-deprecated for zero-downtime upgrades (#4849).resource in MCP::"<server-name>"now work — resource entities (Tool, Prompt, Resource) carry the MCP server as a parent UID so Cedar'sinoperator can traverse the hierarchy (#4965).🐛 Bug Fixes
MCPExternalAuthConfigupstream providers withredirectUriomitted now get the documented{resourceUrl}/oauth/callbackdefault applied by the operator, instead of failing at runtime withredirect_uri is required. Applies to bothMCPServerandVirtualMCPServerflows (#4905).Full commit log
What's Changed
🔗 Full changelog: stacklok/toolhive@v0.22.0...v0.23.0
Configuration
📅 Schedule: (in timezone America/New_York)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Never, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.
Content additions by upstream-release-docs
Source-verified against
stacklok/toolhiveat tagv0.23.1(wasv0.22.0). Two Claude Opus sessions produced this update: a generation pass running theupstream-release-docsskill over all six phases, then a fresh-context editorial pass runningdocs-reviewover the changed files. Prettier and ESLint auto-fixes were applied afterward.Review guidance
Machine-generated reference files under
docs/toolhive/reference/cli/,static/api-specs/, anddocs/toolhive/reference/crds/are synced or regenerated from upstream release assets (separate commit, titled "Refresh reference assets") and should be spot-checked only. Commits authored by the skill contain hand-edited prose; review those for accuracy, not just style. If the "Gaps needing human context" section below is populated, each entry includes a Helper prompt for local Claude that a reviewer can paste verbatim into their local Claude Code session to resolve the gap. Fill those in before merging.Reviewers below are non-bot commit authors in the release range who are also collaborators on this repo.