chore: promote staging 6d68f3a to production - #538
Merged
Merged
Conversation
release-please minted its token from the codegen App, so that App's private key had to live on the production repo. Mint it instead from a dedicated release App whose key is held only in the `release` environment, which deploys from main alone. Also run github-release before release-pr, as release-please-action does, so a release-pr failure cannot stop a merged release from being tagged and the next release PR opens in the same run; add a concurrency group so two quick pushes cannot race; and pin release-please to 16.18.0, which is what `@16` resolves to today. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main is now the only integration branch, so validate-pr-base, which failed every human PR to main unless it carried the target-main label and told contributors to retarget to next, has nothing left to enforce. Remove it, and with it the labeled/unlabeled triggers, which only that job used. Release PRs are about to be opened by the dedicated release App, whose titles come from release-please's title pattern. Exempt its bot from the title check by user ID, the same way the SDK automation App's bot is; that exemption stays, since it opens the promote PRs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The next branch is being retired and PRs now target main. Drop it from release doctor's head-ref condition, which still matches the release-please PRs, and from the tutorial tests' pull_request branches, which keep main. release-doctor.yml is edited rather than deleted: it is generated, and a deletion would be carried as custom code that can conflict with a later regeneration. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The contribution docs still told people to target next and to use the target-main label to get past a base-branch check that no longer exists. Describe main as the only integration branch, point API-surface changes at the spec in the config repo rather than generated files, and add the maintainer rules for promote PRs, human merges and releases. Only the custom Branch model section of CONTRIBUTING.md changes; the generated parts of the file are untouched. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The code generator rewrites `version` on every release. The custom `description` sat on the line right after it, and git treats edits on adjacent lines as one change, so every release made the custom-code replay conflict on pyproject.toml and python codegen stopped building. Keep the generated description so no hand edit borders `version`. A comment explains why; `name` stays between the comment and `version` so the two never touch. The published summary of agentex-client returns to the generator's wording. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ci: retire the next branch and cut releases with the dedicated release App
…ption build(pyproject): keep the generated package description
aringuyen3
approved these changes
Sep 30, 2026
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated promote from the staging trunk, opened by stlc-promote.yml.
Approve this pull request. Do not mark it ready for review and merge it.
It is a draft on purpose: GitHub disables Merge on drafts, and merging this is the one action that breaks the pipeline. This repo allows squash only, so a merge would collapse these commits into one new SHA on production, forking it from the staging trunk and holding all codegen until someone merges production back by hand.
Once CI is green here and this has one approval, re-run
stlc-promote.ymlin the config repo. It fast-forwardsmainonto these exact commits, GitHub closes this pull request as merged, and the trunks stay byte-identical.