459dce2a97
The `dispatch-main-image` job was hard-gated to `triggerdotdev/trigger.dev` on the `main` ref. This makes it configurable via repository variables, all defaulting to the current values: - `MAIN_IMAGE_DISPATCH_REPO` — the repo allowed to dispatch (default `triggerdotdev/trigger.dev`). - `MAIN_IMAGE_DISPATCH_REF_PREFIX` — the ref-name prefix that dispatches, matched with `startsWith(github.ref_name, …)` (default `main`). - `MAIN_IMAGE_DISPATCH_TARGET` — the `repository_dispatch` target (default `triggerdotdev/cloud`). The job is additionally gated on `github.event_name == 'push'`. This is necessary, not just defensive: the gate now keys off `github.ref_name` rather than the computed image tag, and `ref_name` is still `main` when `release.yml` invokes this workflow via `workflow_call` during a release — so without the event guard the job would fire during every release and fail on the absent `CROSS_REPO_PAT`. A version-equality check can't replace it because `build-*` tags strip the prefix to the version output. Behaviour note: the intended dispatch paths — push to `main`, and push of a `<prefix>*` tag in a downstream repo — are `push` events and are unchanged. The one case that no longer dispatches is a manual `workflow_dispatch` run of `publish.yml` on `main` (it previously did, via the old `version == 'main'` check). That path is indistinguishable from a manual release by event name, so `push`-only is the clean discriminator. Dispatching still requires `CROSS_REPO_PAT`, so setting the variables alone doesn't enable anything. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>