Release PR checks can start before the automatic curated-note draft is
published, immediately marking the PR red even though the draft is still
being generated. Applying those notes can also report a stale-head
failure after successfully updating the release branch because the
pull-request API may lag behind the branch ref.
This makes the release flow tolerate those expected ordering delays
without weakening its concurrency checks:
- The required check waits for the initial automatic draft on PR events,
distinguishes a valid but unapplied draft from missing or stale
metadata, and continues through transient GitHub read failures.
- Interrupted refresh runs explicitly close their in-progress check
instead of leaving it spinning indefinitely.
- Post-apply validation reads the canonical release branch ref while
continuing to reject PR-body edits, curated-draft edits, and concurrent
branch movement.
- The prerelease SDK-pin warning points maintainers to `release-deps:
acknowledged` when an intentional cross-package release sequence has not
reached PyPI yet.
Regression coverage exercises delayed draft publication, state changes
during polling, stale pull-request heads after apply, and concurrent
release-branch updates.
`deepagents-code` release PRs currently expose release-please's
generated changelog directly. Maintainers need a durable place to turn
those generated entries into concise, user-facing notes without losing
their edits the next time release-please refreshes the PR.
When a `deepagents-code` release PR moves from draft to ready for
review, the release bot posts a marked comment containing a polished
draft. Maintainers can edit that comment while preserving the generated
version heading, then run `@dcode-release-bot apply` to copy the
finalized section into both `libs/code/CHANGELOG.md` and the release PR
preview.
For a ready, non-bypassed release PR, the `curated release notes` check
binds the latest valid bot-authored draft to its applied metadata,
requires the current version section in `libs/code/CHANGELOG.md` and the
PR-body preview to match that draft, and verifies that the recorded
draft and apply commits remain in the current release branch's ancestry.
Unrelated descendant commits are allowed. If release-please regenerates
the curated section or adds generated entries, the check fails until a
maintainer runs `@dcode-release-bot draft` and then `@dcode-release-bot
apply` again. While a release PR is still a draft, the check passes
without validating curation and the manual commands are disabled. The
exact `release: dangerously skip curated notes` label remains an
explicit escape hatch for exceptional releases.
Drafting makes one non-agentic request to one of three fixed provider
API endpoints, using a repository-configured model. The model receives
isolated release-note input and no callable tools. The trusted helper
reads that prepared input, writes the draft output, and sends the
request using only the selected provider key; the output is structurally
validated and the release snapshot is rechecked before the draft is
published. Privileged curation changes use a short-lived installation
token minted from the existing organization-membership GitHub App, while
workflow feedback and refreshed check runs use the scoped
`GITHUB_TOKEN`. Manual commands require repository write access.
## Required repository setup
- Ensure the installed organization-membership GitHub App credentials
are available as repository secrets `ORG_MEMBERSHIP_APP_CLIENT_ID` and
`ORG_MEMBERSHIP_APP_PRIVATE_KEY`, and that the App grants read/write
access to contents, issues, and pull requests.
- Add repository variables `DCODE_RELEASE_BOT_LOGIN` and
`DCODE_RELEASE_BOT_ID` for the installed App's `<app-slug>[bot]`
identity.
- Configure the `release-dcode` environment without required reviewers
or other deployment approval rules. Set `DCODE_RELEASE_MODEL` to an
`openai:<model>`, `anthropic:<model>`, or `google_genai:<model>` value,
and add the matching provider API key as an environment secret
(`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, or `GOOGLE_API_KEY`).
- Add the literal `curated release notes` job name to `main`'s required
status checks. Without it, failures are visible but do not block a stale
or unapplied release PR from merging.
The release guide includes the exact identity lookup and setup
instructions.