ci(release): trigger the back-merge on workflow_run so it actually fires

[MarTrepodi]

The back-merge workflow has never executed. Not once — gh run list --workflow=backmerge.yml is empty across both v2.2.0 and v2.3.0, which is why both back-merges were done by hand.

Cause

release.yml creates the GitHub Release with gh release create under the default GITHUB_TOKEN. GitHub deliberately suppresses workflow triggers for events raised by that token, to prevent workflows recursively triggering themselves. So on: release: types: [published] can never fire for a release this repository creates.

This is the same class of problem as a bot-authored PR not running pull_request checks — the constraint that shaped #125 and #126.

Worth being explicit: #126 rewrote this workflow's body, and that work was correct but inert, because the workflow it improved was never being invoked.

Fix

on:
  workflow_run:
    workflows: ["comlink-python release"]
    types: [completed]
  workflow_dispatch:

workflow_run is not subject to the same suppression, so it fires when the release workflow finishes. The workflow name is matched against release.yml's own name: — verified in CI rather than eyeballed.

workflow_run fires on completion regardless of outcome, so the job is guarded:

if: >-
  github.event_name == 'workflow_dispatch' ||
  github.event.workflow_run.conclusion == 'success'

A failed release no longer stages a back-merge.

workflow_dispatch is added as a manual escape hatch — it makes the workflow testable without cutting a release, and lets a maintainer stage a back-merge whenever main and develop drift.

One deployment caveat

workflow_run only fires for workflow files present on the default branch. main currently carries the old release:-triggered version, so this fix does not take effect until it reaches main via the next release promotion. The v2.4.0 back-merge is the first one that can fire automatically; until then, workflow_dispatch is available the moment this merges.

🤖 Generated with Claude Code