Skip to content

automation: plugin release → workflow-registry repository_dispatch + auto-bump manifest #79

@intel352

Description

@intel352

Gap

Plugin repos (workflow-plugin-hover, workflow-plugin-namecheap, workflow-plugin-digitalocean, etc.) ship new tags but the registry doesn't update automatically. Every release currently needs a manual PR like #78 to bump `plugins//manifest.json` version + downloads.

What exists

`.github/workflows/build-pages.yml` accepts `repository_dispatch: types: [plugin-release]`. Nothing fires it — pure latent capability.

Proposed fix (two pieces)

Piece 1 — fire from plugin repos

Add a `notify-registry` step to every plugin repo's `release.yml`, after the `gh release edit --draft=false` step:

```yaml

  • name: Notify workflow-registry
    env:
    GH_TOKEN: ${{ secrets.RELEASES_TOKEN }}
    run: |
    gh api repos/GoCodeAlone/workflow-registry/dispatches \
    -f event_type=plugin-release \
    -F client_payload[plugin]=${{ github.event.repository.name }} \
    -F client_payload[tag]=${{ github.ref_name }}
    ```

Piece 2 — auto-bump source manifest on dispatch

Currently `build-pages.yml` on dispatch just rebuilds the index from the EXISTING source manifests. Add a new step (or a sibling workflow) that:

  1. Reads `client_payload.plugin` + `client_payload.tag`.
  2. Fetches the release's `checksums.txt` from `releases/download//`.
  3. Updates `plugins//manifest.json` — version, downloads[] urls + sha256s.
  4. Validates via `scripts/validate-manifests.sh`.
  5. Commits + opens a PR (or direct-pushes — operator decides safety preference).

A new `scripts/auto-bump-plugin.sh ` would be the natural place for the manifest mutation logic. The dispatch handler workflow shells out to it.

Affected plugin repos (G1 piece 1 needs adding to each)

  • workflow-plugin-hover
  • workflow-plugin-namecheap
  • workflow-plugin-digitalocean
  • workflow-plugin-aws / gcp / azure
  • workflow-plugin-tofu
  • workflow-plugin-ci-generator
  • ... and all the other privates that ship via the GoCodeAlone goreleaser pattern

Why this matters

Without it, plugin shipping looks like: `tag → wait → manual workflow-registry PR with checksums copied by hand`. That's the gap that surfaced when shipping hover@v0.2.0 → registry#78 today.

Discovered in

DNS delegation pipeline arc — workflow-plugin-hover v0.2.0 ship.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions