Pin repobuddy/.github shared workflows to @v1 (needs @changesets/cli v3 first)

[unional]

Pin the shared repobuddy/.github workflows to @v1 instead of @main, once that tag is cut.

Why

repobuddy/.github is being tagged for the first time. Today this repo pins those shared workflows at @main, which means it takes every change to them the moment it merges — including breaking ones nobody reviewed.

That is not theoretical. changesets/action was upgraded v1 → v2 in repobuddy/.github by an auto-merged Renovate PR, and it silently broke the changesets release path in every repo consuming it (repobuddy/.github#43). Pinning a tag means a change like that waits for a release someone deliberately cuts.

Consumers pin @v1 — a moving alias re-pointed on each backward-compatible release, so you still get fixes automatically, but never a breaking change. See the "Versioning" section of the repobuddy/.github README (added in repobuddy/.github#44).

Exact changes

Four files — note pull-request.yml and update-snapshot.yml were missing from the original consumer inventory.

.github/workflows/github-page.yml

 jobs:
   docgen:
     permissions:
       contents: write
-    uses: repobuddy/.github/.github/workflows/pnpm-docs.yml@main
+    uses: repobuddy/.github/.github/workflows/pnpm-docs.yml@v1
     with:
       publish-dir: ./packages/storybook-addon-vis/storybook-static

.github/workflows/pull-request.yml

       - name: Install playwright browsers
-        uses: repobuddy/.github/.github/actions/setup-playwright@main
+        uses: repobuddy/.github/.github/actions/setup-playwright@v1

.github/workflows/update-snapshot.yml

       - name: Install playwright browsers
-        uses: repobuddy/.github/.github/actions/setup-playwright@main
+        uses: repobuddy/.github/.github/actions/setup-playwright@v1

.github/workflows/release.yml

       - name: Install playwright browsers
-        uses: repobuddy/.github/.github/actions/setup-playwright@main
+        uses: repobuddy/.github/.github/actions/setup-playwright@v1

   release:
-    uses: repobuddy/.github/.github/workflows/pnpm-release-changeset.yml@main
+    uses: repobuddy/.github/.github/workflows/pnpm-release-changeset.yml@v1
     needs: verify
     secrets: inherit
 
   docgen:
     permissions:
       contents: write
-    uses: repobuddy/.github/.github/workflows/pnpm-docs.yml@main
+    uses: repobuddy/.github/.github/workflows/pnpm-docs.yml@v1
     needs: release
     if: github.ref == 'refs/heads/main' && needs.release.outputs.published == 'true'
     with:
       publish-dir: ./packages/storybook-addon-vis/storybook-static

Precondition — do not skip

pnpm-release-changeset.yml uses changesets/action@v2.0.0, which validates that your repo is on @changesets/cli v3 and fails outright for v2 users (changesets/action#699).
This repo is on "@changesets/cli": "^2.29.8", so the release.yml changesets line must not be pinned until this repo upgrades to @changesets/cli v3. No upgrade is in flight here that I could find — unlike repobuddy/repobuddy, which has one open (repobuddy/repobuddy#581).

Suggested order:

1. Upgrade @changesets/cli to ^3.0.0 and confirm a release works.
2. Wait for repobuddy/.github to cut v1.0.0 (blocked on fix(pnpm-release-changeset): use changesets/action v2 input names, and put the shared workflows on tags .github#44).
3. Apply all four files above.

The three setup-playwright pins and the pnpm-docs.yml pins have no CLI dependency and can move as soon as the tag exists. Only the pnpm-release-changeset.yml line is gated, so this can be split.

Worth watching here specifically

Your docgen job gates on needs.release.outputs.published == 'true'. changesets/action@v2.0.0 changed how that output is produced — stdout parsing was replaced by a shared output file via the CHANGESETS_OUTPUT env var, which "should always be passed down to the Changesets CLI invocations" when custom publish scripts are used (changesets/action#678), and the action now warns rather than fails when that file is missing (changesets/action#697).

The shared workflow uses a custom publish script (pnpm run release). If that env var does not reach the CLI, published can come back wrong and your docs deploy would silently stop running. This is unverified — it cannot be tested outside a real release — so watch the first release after pinning.

Note

Until then this repo stays on @main, which already carries changesets/action@v2 — so the release path is already mismatched with CLI v2 today. Pinning does not cause that; the v3 upgrade fixes it.

Also: .github/dependabot.yml here has an npm entry only and no github-actions ecosystem, so Dependabot will not bump these refs. Renovate will.

[unional]

Done — landed ahead of what this issue asked for.

All shared-workflow refs are now pinned to @v2 (this issue predates the v2 tag):

• .github/workflows/pull-request.yml, release.yml, update-snapshot.yml → setup-playwright@v2
• .github/workflows/github-page.yml, release.yml → pnpm-docs.yml@v2
• .github/workflows/release.yml → pnpm-release-changeset-oidc.yml@v2

The precondition is satisfied: this repo is on "@changesets/cli": "^3.0.0".

Deviation from the plan above: the release job uses the OIDC variant (pnpm-release-changeset-oidc.yml) rather than pnpm-release-changeset.yml, per #846.

The "worth watching" risk is cleared. The concern was that changesets/action@v2's new CHANGESETS_OUTPUT handling could make needs.release.outputs.published come back wrong and silently skip the docs deploy. A real publishing release has since run (chore: version packages, https://github.com/repobuddy/visual-testing/actions/runs/32357925316) with both release / release and docgen / publish-github-pages succeeding, so the output plumbing works end to end.