chore: autorelease single source of truth#90
Merged
Conversation
…of truth This PR completes the de-Stainless migration: * Strip the "File generated from our OpenAPI spec by Stainless" header comment from every auto-generated .py file (248 files). * Rename wire-protocol HTTP headers: X-Stainless-* -> X-Fireworks-* in _base_client.py, _client.py, _constants.py, _utils/_utils.py, and the matching test assertions. The X-Fireworks-Lang/-Package-Version/-OS/ -Arch/-Runtime/-Async/-Retry-Count/-Read-Timeout/-Raw-Response headers ship on every request; server-side will be updated to read the new prefix. * Rename internal token "____stainless_override_cast_to" -> "____fireworks_override_cast_to" and "stainless-python-retry-..." retry id prefix -> "fireworks-python-retry-...". * Delete the release-please pipeline artefacts: .release-please-manifest.json, release-please-config.json, .stats.yml. The version-bump tool now reads pyproject.toml directly as the single source of truth. * release-tag.yml now reads the version from pyproject.toml on the merged commit. No commit-subject regex, no dispatch-input override, no manifest fallback. Single source of truth. The "Mark release PR as tagged" step also drops its || true masks: a missing PR association or a failed label flip is a loud error, not silently swallowed. * release-doctor.yml branch-name filter switched from "release-please" to "autorelease/" prefix; companion PR in staging renames the release PR branch to autorelease/next. * Strip remaining Stainless mentions from README.md, CLAUDE.md, llms.txt, pyproject.toml comments, lib/.keep markers, and _legacy_compat.py docstring. * SECURITY.md: drop Stainless contact, consolidate on security@fireworks.ai as the sole reporting address for this SDK. CHANGELOG.md historical entries that reference Stainless are preserved as-is (history, not current state).
Hecate0821
commented
May 21, 2026
Collaborator
Author
Hecate0821
left a comment
Hecate0821
left a comment
There was a problem hiding this comment.
Found one release workflow recovery issue while checking the handover sequencing.
| fi | ||
|
|
||
| tag="v${version}" | ||
| if git rev-parse -q --verify "refs/tags/${tag}" >/dev/null; then |
Collaborator
Author
There was a problem hiding this comment.
This makes the label-flip step unrecoverable after a partial failure. If Create tag and GitHub Release succeeds but Mark release PR as tagged fails, a rerun will hit this branch, set skip=true, and skip the label flip again, even though the comment below says rerunning is the recovery path. That leaves the release PR stuck with autorelease: pending. Consider separating tag_exists from skip_label_update, or making the tag/release creation idempotent while still running the PR label update when the tag already exists at GITHUB_SHA.
Collaborator
Author
There was a problem hiding this comment.
Addressed in 791d518. Split the gate so tag existence only skips tag/Release creation; the label-flip step now runs unconditionally and is a no-op when no PR is associated or the PR is not in autorelease: pending. A rerun after a partial failure (tag created, label flip failed) will now flip the label cleanly. Loud failure preserved for the case where the tag was just created in this run but no PR is associated.
If "Create tag and GitHub Release" succeeded but "Mark release PR as tagged" failed (transient API hiccup), the previous structure exited early on rerun via the `skip=true` path because the tag now existed, leaving the release PR stuck at `autorelease: pending` forever. Split the gate: tag existence only skips tag/release creation. The label-flip step now runs unconditionally and is a no-op when there is no PR for the commit or the PR is not in `autorelease: pending` state. A run that just created the tag but cannot find an associated PR still fails loudly to surface misconfigured release commits. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Closed
Pulls the generated-code changes (Stainless boilerplate strip across 248 .py files + X-Stainless-* wire-header rename) out of this PR. They move to a separate follow-up PR. What stays: - .github/workflows/release-tag.yml rewritten to read version from pyproject.toml [project] (no manifest fallback, no commit-subject regex, no workflow_dispatch override). The label-flip step runs unconditionally and is a no-op when no PR is associated or the PR is not in `autorelease: pending`, so a partial-failure rerun recovers cleanly. This is the root-cause fix for the PR #88 stale-title incident. - .github/workflows/release-doctor.yml branch filter switched from release-please/ to autorelease/ to match the new bumper. - .release-please-manifest.json and release-please-config.json deleted (the new bumper reads pyproject.toml directly and inlines the changelog-sections + extra-files lists). What is reverted: - All 248 generated .py files under src/ and tests/ restored to main state (Stainless boilerplate header back, X-Stainless-* wire headers back). - {CLAUDE.md, README.md, SECURITY.md, llms.txt, pyproject.toml, src/fireworks/lib/.keep, src/fireworks/lib/_legacy_compat.py} restored to main. - .stats.yml restored (Stainless overlay artifact). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hecate0821
changed the title
Closed
Merged
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.
Scaled back. This PR now only does the autorelease SST root-cause fix for the PR #88 stale-title incident, leaving generated SDK code and the Stainless overlay untouched. Both will move to separate follow-up PRs.
What this PR changes (4 files)
release-tag.yml— reads version frompyproject.toml [project] version. No commit-subject regex, no.release-please-manifest.jsonfallback, noworkflow_dispatchversionoverride. The label-flip step runs unconditionally and is a no-op when no PR is associated or the PR is not inautorelease: pending, so a partial-failure rerun recovers cleanly.release-doctor.yml— branch filter switched fromrelease-please/toautorelease/to match the new bumper output in the staging-sidefw-ai/fireworks#26434..release-please-manifest.json— deleted. The new bumper readspyproject.tomldirectly.release-please-config.json— deleted. The new bumper inlineschangelog-sectionsandextra-filesas module constants.What this PR does NOT change
.pyfiles undersrc/andtests/— Stainless boilerplate header andX-Stainless-*wire headers stay as-is.CLAUDE.md,README.md,SECURITY.md,llms.txt,pyproject.toml,lib/.keep,_legacy_compat.py— restored to main..stats.yml— restored (Stainless overlay artifact).Merge order
Must merge after
fw-ai/fireworks#26434, which contains the matchingsdk_release_bump.pyrewrite. Without that, the next promote crashes on the now-deletedrelease-please-config.json.