[hdamker]

What type of PR is this?

• cleanup

What this PR does / why we need it:

Three jobs of the Release Automation workflow become one finalize job: update-issue (shown as sync-issue), post-result and create-sync-pr.

finalize runs after the command jobs, also when one of them failed (always()). Its only condition is the new finalize output of plan: true for a command or event that runs, false for rejections, configuration errors and the publish confirmation request. One Python entry point, release_automation/scripts/finalize.py, reads toJSON(needs) and runs, in this order:

1. after a publication: the post-release sync PR (sync_pr.py, from refactor(ra): add sync_pr.py and the common-file sync to common_sync.py #485)
2. when the command, issue event or sync asks for it: the common sync if the cache is stale (sync_common(), from refactor(ra): add sync_pr.py and the common-file sync to common_sync.py #485), then the Release Issue sync and its comments (issue_created, state_not_planned, common_sync_pr_created, common_sync_failed)
3. for a slash command: the result comment, which updates the acknowledgment
4. after a publication: the published Release Issue

The conditions of the three former jobs and steps are now Python functions with tests (test_finalize.py), as are "Resolve Sync Context", "Determine Result Template", "Resolve Reason" and "Build Result Context".

Published Release Issue (closes #153): IssueSyncManager.finalize_published_issue() replaces the inline JavaScript and the unused close_release_issue(). It writes the same STATE and ACTIONS text, including the post-publish warnings, swaps the state label to release-state:published, and closes the issue only when the sync PR status is created. API errors are logged and never fail the job. As before, this step runs only after the result comment was posted.

Also:

• state_not_planned is now posted. The former step compared the state to not_planned, but the state value is not-planned, so the comment never appeared
• the sync-release-issue composite is removed; its Python is issue_sync.sync_for_workflow(), called by finalize
• post-bot-comment and finalize render through the same BotResponder.render_comment() (base context plus delta, apis_json to apis)
• the result comment of /sync-issue stays interim_processing, as before
• the RA canary checks the finalize job instead of the job named sync-issue
• finalize writes a short step summary: trigger, release, sync PR, common sync, Release Issue, result comment

Comments, labels and Release Issue sections are otherwise unchanged. The Release Issue sync now runs before the result comment; before, the two were separate jobs that ran side by side.

Workflow: 1,327 lines (from 2,353 at the slice start), 8 jobs (from 10), 6 tooling checkouts (from 7), 8 github-script blocks (from 11).

Which issue(s) this PR fixes:

Fixes #153
Part of #476

Special notes for reviewers:

Targets release-automation-refactor. The branch canary on ReleaseTest2 and a manual end-to-end run follow after merge: a stale common-file cache first, then create, review merge, draft, publish, sync PR and issue close.

Changelog input

 release-note

Additional documentation

docs