Update cli-plugins catalog on release; fix goreleaser double-run

[scotwells]

Two related release-pipeline changes.

Fix: goreleaser ran twice per release

Publishing a release through the GitHub UI creates the tag, which fires both push: tags and release: published. The plugin job was gated on the tag ref (startsWith(github.ref, refs/tags/v)), which is true for both events — so goreleaser ran twice concurrently, with two processes racing to upload the same release assets.

The plugin-publishing job is now gated on github.event_name == release, so it runs exactly once (on the release event) and has a real release to attach artifacts to. The validate-kustomize, publish-container-image, and publish-kustomize-bundle jobs are unchanged.

Feature: auto-update the datumctl plugin catalog

Adds an update-plugin-index job that runs after goreleaser attaches the archives + checksums.txt. In a single job it (1) mints a short-lived, repo-scoped installation token from the milo-os GitHub App, and (2) calls the datum-cloud/actions/update-plugin-index composite action, which opens a PR against milo-os/cli-plugins bumping plugins/ipam.yaml to the released version — refreshed per-platform URLs and checksums from checksums.txt, and a link back to the release. This replaces the manual manifest edit after each release.

Mint + call live in the same job on purpose: a GitHub App token minted in a separate job and passed via outputs is scrubbed to empty (masked values don't survive job-to-job hops), so a composite action — not a reusable workflow — is required. Verified end-to-end against the v0.2.0 assets.

Pinning

The update-plugin-index step pins datum-cloud/actions/update-plugin-index@feat/update-plugin-index-composite (datum-cloud/actions#85) until the composite action ships in a tagged release; switch to a version tag (e.g. @v1.18.0) once that release is cut.

Required setup — milo-os GitHub App

Cross-repo PRs need a token the built-in GITHUB_TOKEN can't provide (it only reaches this repo). This pipeline mints a short-lived, repo-scoped token from a GitHub App in the milo-os org — no long-lived PAT. One-time setup by an org admin:

1. Create the App — milo-os org → Settings → Developer settings → GitHub Apps → New GitHub App.
   • Name: e.g. milo-plugin-index-updater.
   • Uncheck Active under Webhook (none needed).
   • Repository permissions: Contents → Read and write; Pull requests → Read and write.
   • Where can this App be installed: Only on this account.
   • Create it, note the App ID, and generate a private key (downloads a .pem).
2. Install the App on the milo-os org, scoped to the cli-plugins repository (add other plugin index repos later as needed).
3. Add secrets — org-level Actions secrets (shared by every milo plugin repo) or repo-level on milo-os/ipam:
   • PLUGIN_INDEX_APP_ID — the App ID
   • PLUGIN_INDEX_APP_PRIVATE_KEY — the full contents of the .pem

The workflow's generate-index-token job exchanges these for an installation token scoped to milo-os/cli-plugins (expires ~1h), which the catalog-update job uses to open the PR.

Related work

• Composite action this job calls: Convert update-plugin-index to a composite action datum-cloud/actions#85
• Builds on the plugin release tooling: Make the IPAM CLI plugin installable via datumctl #65
• Catalog entry it keeps up to date: Register the IPAM CLI plugin cli-plugins#1
• datumctl plugin marketplace: Open the datumctl plugin marketplace to third-party catalogs datum-cloud/datumctl#224 (design: Third-party plugin indexes & marketplaces for datumctl datum-cloud/enhancements#783)