ci(release): trigger changelog sync directly from the release workflows

[yonib05]

Description

python/v1.47.0 and typescript/v1.8.0 released but the changelog didn't sync. Root cause: Changelog: Sync listens for on: release, but the release workflows create the GitHub release with the built-in GITHUB_TOKEN, and GitHub deliberately does not emit release/push/workflow events for actions taken by GITHUB_TOKEN (a guard against recursive workflow triggers). So on: release has never fired from an actual release — only the daily cron backstop eventually caught up.

This dispatches Changelog: Sync explicitly from each release workflow's create-gh-release job, right after the release is created, passing the new tag:

- name: Trigger changelog sync
  continue-on-error: true
  env:
    GH_TOKEN: ${{ github.token }}
    NEW_TAG: ${{ needs.scan-commits.outputs.new_tag }}
  run: gh workflow run changelog-sync.yml -f tag="$NEW_TAG"

• workflow_dispatch is an explicit API call, not an event, so the GITHUB_TOKEN recursion guard does not apply — this fires reliably.
• The job gains actions: write (needed to dispatch a workflow).
• continue-on-error: a changelog hiccup must not fail a release whose tag already published; the daily cron still backstops.
• Reuses the existing Changelog: Sync workflow unchanged as the single source of truth for generation + PR-opening.

The standalone on: release trigger and the daily cron in changelog-sync.yml are left in place as defense-in-depth.

Testing

• Both release workflows validate as YAML.
• The dispatch mechanism itself is proven: the two backfill PRs for these releases (docs(changelog): sync strands-agents/harness-sdk python/v1.47.0 #3186 python/v1.47.0, docs(changelog): sync strands-agents/harness-sdk typescript/v1.8.0 #3187 typescript/v1.8.0) were produced by manually dispatching Changelog: Sync with a tag — the exact call this step automates.
• Note: fully exercising the release-triggered path requires an actual (non-dry-run) release; the changelog step is decoupled + continue-on-error so it cannot regress a release.

[github-actions]

Assessment: Approve

Correct, well-scoped fix. The root-cause analysis (GITHUB_TOKEN-created releases don't emit release events, but workflow_dispatch is an explicit API call unaffected by the recursion guard) is accurate, and the implementation is sound.

Verification notes

• Contract: gh workflow run changelog-sync.yml -f tag= matches the required tag input on changelog-sync.yml's workflow_dispatch, and that workflow's if runs for non-release event names — so the dispatch executes.
• Permissions: actions: write correctly added; scoped to the create-gh-release job only.
• References: needs.scan-commits.outputs.new_tag is valid in both files (job declares the dependency).
• Safety: job-level if: inputs.dry_run != true means no dispatch on dry runs; continue-on-error keeps a changelog hiccup from blocking the downstream publish jobs.
• Parity: Python and TypeScript workflows carry identical blocks.

Only one optional, non-blocking suggestion inline (surface silent dispatch failures via a warning annotation).

Nicely done — the inline comments explaining the why behind each change are exemplary.

[github-actions]

Re-reviewed after 70dbb86 (+ merge from main). The follow-up fully addresses my earlier suggestion — and cleaner than proposed: dropping continue-on-error in favor of || echo "::warning::..." is the right call, since with the default bash -eo pipefail shell the || already short-circuits errexit and guarantees the step exits 0, making continue-on-error redundant. A failed dispatch now surfaces a warning annotation immediately instead of waiting on the daily cron.

Both workflows validate as YAML and remain in parity. No remaining concerns — Approve stands. 🚢

[github-actions]

Re-reviewed after 70dbb86 — the observability follow-up is resolved, and cleanly. Dropping continue-on-error in favor of gh workflow run … || echo "::warning::…" is actually better than my original suggestion: the || already forces the step to exit 0, so continue-on-error was redundant, and now a failed dispatch shows a visible warning annotation instead of a silently-green step. Parity between the Python and TypeScript workflows is maintained, and all workflows still validate as YAML.

Assessment: Approve — no outstanding issues. Nice iteration. 🚀

[opieter-aws]

@strandly-the-agent Review this pr

[strandly-the-agent]

Assessment: Approve — clean, well-scoped CI fix. I re-checked out the branch (121b6d5), independently verified the dispatch contract, and every claim in the PR body and prior reviews holds. No blocking or should-fix findings from me.

What I verified (independent pass)

Check	Result
Dispatch contract	✅ gh workflow run changelog-sync.yml -f tag= matches changelog-sync.yml's workflow_dispatch.inputs.tag (required: true, type: string)
Sync runs on dispatch	✅ its job if is `github.event_name != 'release'
Recursion-guard reasoning	✅ correct — GITHUB_TOKEN-created releases don't emit a release event; workflow_dispatch is an explicit API call unaffected by the guard
Permissions	✅ actions: write is the minimal grant needed to dispatch, scoped to the create-gh-release job only
new_tag reference	✅ needs.scan-commits.outputs.new_tag valid — job declares needs: [scan-commits, draft-notes, approve-release]
No dry-run dispatch	✅ job-level if: inputs.dry_run != true; also gated behind reviewer approve-release
Ordering / no race	✅ tag + release are pushed/created before the dispatch step, so the sync run always sees the tag
Failure handling	✅ `
Parity	✅ the added blocks in release-python.yml and release-typescript.yml are byte-identical (only the publish-target comment differs)
YAML	✅ all three workflows parse (yaml.safe_load)

Notes (non-blocking, no action needed):

• gh workflow run only reports the dispatch API result, not the sync run's outcome — so the warning catches a failed dispatch, not a failed sync. That's intentional and correct: sync failures surface in the Changelog: Sync run itself, with the daily cron as backstop. The comment wording ("Failed to dispatch") is accurate.
• The new dispatch path and the daily cron can in principle both run, but that's already-documented accepted behavior in changelog-sync.yml (cross-event duplicate PRs are content-identical and closed manually), and branch names are keyed by tag — no new risk introduced here.
• The empty-new_tag edge is pre-existing (the tag-creation step already dereferences NEW_TAG) and not introduced by this change.

Root-cause writeup and the inline why comments are genuinely good. Flagging for a human maintainer to give the actual approving click — this is just my independent read.