ci: notify data-plane-infrastructure when a release is published

[duanshiqiang]

Why

data-plane-infrastructure now has a workflow that opens a PR bumping the BYOC onboarding wrapper modules to the newest release here (data-plane-infrastructure#25693). That PR is what carries an onboarding change into the dev test accounts: the dev terragrunt units source their wrapper from the working tree, so bumping the wrapper's ?ref= changes what they resolve to, Atlantis plans them on the PR, and applying it deploys.

It declares a repository_dispatch trigger but nothing sends it. auto-release.yaml only cuts the release, and its built-in GITHUB_TOKEN cannot dispatch across repositories. This adds the missing producer.

What

notify-onboarding-release.yaml, triggered on release: published, which mints a scoped app token and posts byoc-onboarding-released to data-plane-infrastructure.

It fires for hand-cut releases as well as automated ones, which is deliberate — the README notes manual tagging is still supported for releases needing curated notes, and those should reach dev the same way. Adding a job to auto-release.yaml instead would have missed them.

This is purely a latency improvement. The consuming workflow also polls on a weekday-morning schedule, so without this a release is picked up the next morning rather than within a minute. Nothing depends on this job succeeding; the release has already been published by the time it runs.

Not yet functional

WORKFLOW_AUTH_APP_ID and WORKFLOW_AUTH_PRIVATE_KEY are organization secrets that this repository cannot currently read — the org secrets available here are the CLICKHOUSE_CI_*, INTEGRATIONS_TEAM_*, ROBOT_CLICKHOUSE_*, COVERITY_TOKEN and DOCKER_ROBOT_PASSWORD set, and neither WORKFLOW_AUTH secret is among them.

So someone with organization admin needs to grant this repository access to those two secrets before the workflow does anything. Until then the job fails at the token step on each release. The consuming schedule keeps working regardless, so nothing regresses in the meantime — this just stays inert.

ROBOT_CLICKHOUSE_COMMIT_TOKEN is visible here and would probably work, but a broad robot PAT is a worse credential for this than an installation token scoped to one repository and one permission. Worth saying explicitly in case someone suggests it as a shortcut.

Notes on the implementation

The token is scoped to data-plane-infrastructure with permission-contents: write, which is what the repository dispatch API requires and nothing more.

The token action is pinned to a SHA rather than a tag, unlike the other actions in this repository. It mints a credential with write access to another repository, so it seemed worth not tracking a mutable tag. It's the same pin data-plane-infrastructure already uses.

The tag and release URL are passed through env rather than interpolated into the run block, since ${{ }} is substituted before the shell sees it and a release tag is user-supplied.

Verification

The YAML parses, the run block is shellcheck-clean, and the event_type this sends matches the types: the consumer listens for:

producer sends: event_type=byoc-onboarding-released
consumer wants: types: [byoc-onboarding-released]

End to end it cannot be tested until the secrets are granted.