Skip to content

Add Temporal-backed release automation - #2995

Open
eamsden wants to merge 45 commits into
mainfrom
eamsden/temporal-release-automation-python
Open

Add Temporal-backed release automation#2995
eamsden wants to merge 45 commits into
mainfrom
eamsden/temporal-release-automation-python

Conversation

@eamsden

@eamsden eamsden commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

What changed?

  • Automate release with one Temporal workflow implemented in Python.
  • Start and complete a release from the GitHub Actions run triggered when an SDK owner merges one valid release-note file.
  • Build the fixed native matrix and signed Maven payload, freeze their GitHub Actions artifact identities in Workflow state, publish Maven with bounded ambiguity recovery, then create the GitHub draft, attach assets, and make it public.
  • Keep release- and Maven-generation-specific task queues, GitHub App publication authentication, global publication concurrency, and credential-free candidate compilation.
  • Remove timers, separate approval and ownership workflows, manual takeover and recovery UI, and the former manual release workflow.

Why?

The current manu-matic Java release process contains footguns which have led to incidents. There is also enough fragility in the GitHub and Maven release process that dogfooding Temporal here seems reasonable. The Python implementation keeps the necessary orchestration and reconciliation in one readable operational path.

Breaking changes?

No SDK API changes.

The former manual prepare-release path is intentionally removed. Merging a valid release-note file is the release authorization and execution trigger.

Verification

  • 8 focused local tests using the Temporal ephemeral test server and mocked publication activities
  • Ruff formatting and lint
  • Strict mypy
  • uv lock consistency
  • Shell syntax and deterministic native/Maven archive smoke checks
  • Workflow YAML parsing, pinned Action validation, and permission-boundary checks
  • No scheduled or manual dispatch entrypoint in the Temporal release workflow

No release, test release, Maven publication, tag, GitHub release, or external Temporal operation was run while developing or testing this change.

Server PR

None.

Supersedes #2986.

@eamsden
eamsden force-pushed the eamsden/temporal-release-automation-python branch from fa2ee95 to 551ff6c Compare August 10, 2026 19:35
@eamsden
eamsden marked this pull request as ready for review August 10, 2026 19:36
@eamsden
eamsden requested a review from a team as a code owner August 10, 2026 19:36
@eamsden eamsden changed the title Add concise Temporal-backed Python release automation Add Temporal-backed release automation Aug 11, 2026
@eamsden
eamsden force-pushed the eamsden/temporal-release-automation-python branch from 83b51f2 to 23eb331 Compare August 11, 2026 20:05
eamsden added 23 commits August 19, 2026 11:41
Orchestrate immutable sdk-java release candidates with transient GitHub Actions Workers, a no-input approval Update, privileged publication queues, and exact-state external reconciliation.
Make release progress explicitly staged and controllable, bind approval to a locked release-specific GitHub issue, and make Maven and GitHub publication reconciliation safe across ambiguous retries. Add a durable emergency handoff path, frozen Worker routing, prompt Activity cancellation, idempotent native builds, and focused local tests.
Harden the Temporal state machine, publication reconciliation, approval recovery, and transient Worker behavior. Add protected Maven generation authorization, draft-first exact asset handling, maintenance-branch recovery, and both automated and independent emergency paths.
Bind release workflows to the exact receipted Candidate run, separate candidate compilation from credentialed artifact storage, adopt fallback artifacts across reruns, and classify S3 absence without masking service failures.
@eamsden
eamsden force-pushed the eamsden/temporal-release-automation-python branch from 6bc0da5 to 6a5fc24 Compare August 19, 2026 16:45

@cconstable cconstable left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial review. Didn't get through everything, will take another pass.

_, portal = self.repository_state(profiles, manual)
portal_id = prior.portal or portal
state = await self.portal_state(portal_id) if portal_id else ""
if profiles or manual and (manual[0].get("state") != "released" or state != "FAILED"):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and has a higher precedence than or so this is evaluated as profiles or (manual and ...) which I don't think was the intention

session = Session(value, self.source, self.environment)
try:
artifacts = [
await session.artifact(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this can throw a ReleaseError (L458) but no except to capture it. looks like that would cause retries until the start_to_close_timeout hits.

session.temp.cleanup()

@activity.defn(name="inspectMaven")
async def inspect_maven(self, value: ReleaseInput) -> Inspection:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't seen any heartbeats in the activities so far. Might be good to add so we can distinguish between a worker dying vs the activity just taking a long time. We would need to add a heartbeat_timeout to the execute_activity options.

Comment on lines +799 to +801
root, records = await session.materialize()
await session.maven(root, records)
return await session.github_release()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it possible to make these separate activities? in the event that gh is having issues publish would fail we would have to re-materialize. probably fine but something to think about.

@@ -1,38 +0,0 @@
# sdk-java Github Workflows

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A new README would be helpful as I'm still not quite sure I've got the whole flow mapped out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants