ci: bump skill spec.version when Renovate bumps spec.ref

[rdimitrov]

Summary

• Adds .github/workflows/renovate-post-upgrade.yml that runs on Renovate-authored PRs touching skills/**/spec.yaml. For each file whose spec.ref changed (and whose spec.version did not), it patch-increments spec.version (e.g. 0.1.0 → 0.1.1) and pushes the bump back to the same PR branch with DCO sign-off.

Why

Dockyard's existing customManagers regex in renovate.json auto-bumps spec.ref to track upstream main, but spec.version stays unchanged. The build pipeline reads .spec.version and tags the OCI artifact accordingly, so today the same :0.1.0 tag gets republished with new bytes whenever Renovate moves the ref — a silent re-pin.

Downstream consumers (most directly stacklok/toolhive-catalog, which holds two pointers to the same content per skill: an OCI tag and a git ref) can't detect this with their own Renovate docker datasource because the tag string doesn't change. The catalog has been working around this manually (e.g. stacklok/toolhive-catalog#1179) and a parallel sync workflow has been proposed (stacklok/toolhive-catalog#1178).

This workflow closes the drift at the source: any new ref also gets a new version, so a new tag is always published, and downstream Renovate-style flows can react normally. The catalog-side companion PR (stacklok/toolhive-catalog#1182) then rewrites its ref in lockstep with the new tag.

Behavior

• Triggered only by renovate[bot] (if: github.actor == 'renovate[bot]'), so manual edits to spec.yaml by humans aren't auto-bumped — the maintainer is expected to choose the version.
• Skips files where spec.ref is unchanged or where the maintainer has already updated spec.version in the same PR.
• Fails the workflow (rather than silently rewriting) when:
  • spec.version isn't simple X.Y.Z semver (can't auto-bump unambiguously).
  • The sed substitution can't locate the version line to replace.
• Surgical sed-based replacement preserves the file's comments, key order, and indentation.

Notes

• Dockyard does not currently use a GitHub App token in workflows, so this uses secrets.GITHUB_TOKEN. As a side effect of how GitHub handles GITHUB_TOKEN-authored pushes, the existing CI checks on the PR won't auto-rerun on the bump commit. The bump itself is mechanical (single-line version increment) and is validated by this workflow; if a maintainer wants a fresh CI run after the bump, an empty re-run via the Actions UI suffices.
• The workflow will not re-trigger itself on the bump commit because the second pull_request event's github.actor is github-actions[bot], not renovate[bot], so the if gate skips it.

Test plan

• Wait for the next Renovate cycle on a skills/*/spec.yaml (or simulate one via workflow_dispatch after a manual ref bump on a test branch) and confirm:
  • the workflow runs only on Renovate-authored PRs;
  • the resulting bump commit changes only the spec.version line;
  • the OCI publish in build-skills.yml (post-merge) tags the new artifact under the bumped version.
• Confirm a non-Renovate PR touching spec.yaml does not trigger the bump.

[rdimitrov]

Let's hold on merging this until I figure out the right way :D

[rdimitrov]

Superseding with a smaller change: instead of a follow-up workflow that bumps spec.version, derive the OCI tag from spec.version + spec.ref so a single Renovate ref bump always produces a new immutable tag. New PR coming.