Skip to content

chore: reset release-please state to re-cut v1.0.0 - #17

Merged
jmgilman merged 1 commit into
masterfrom
session-007/reset-v1.0.0-release
Apr 23, 2026
Merged

jmgilman merged 1 commit into
masterfrom
session-007/reset-v1.0.0-release

Conversation

@jmgilman

Copy link
Copy Markdown
Contributor

Summary

  • Re-seeds release-please state so the next run proposes v1.0.0 fresh.
  • Adds the meigma-release-please App (id 3342783) to the tag ruleset's bypass list so release-please can actually push the v1.0.0 tag this time. Expressed as `type = "integration"` with an explicit App ID (the slug form requires an App-authorized token to resolve; the integration-id form does not).
  • Reverts the populated CHANGELOG.md and manifest bump from PR chore(master): release 1.0.0 #9; release-please will regenerate both on the next release cycle.

Why

When PR #9 merged, release-please bumped the manifest + populated CHANGELOG.md but failed to push the `v1.0.0` git tag because the App was blocked by the tag ruleset. That left master in a stuck state:

  • manifest says `1.0.0`
  • CHANGELOG has v1.0.0 entries
  • but no `v1.0.0` tag exists, and the draft release was sitting in GitHub with an `untagged-*` URL

Release-please then helpfully opened PR #14 proposing v1.1.0, compounding the confusion.

Out-of-band cleanup already done:

  • Ruleset bypass pushed live via `scripts/configure_github_repo.py` (note: script uses PATCH which returned 404 for unclear reasons; ultimately succeeded via PUT).
  • Draft `v1.0.0` release deleted.
  • PR chore(master): release 1.1.0 #14 closed, `release-please--branches--master` branch deleted.
  • `autorelease: tagged` label stripped from PR chore(master): release 1.0.0 #9 (PR is merged and archival; label was just confusing release-please's duplicate-detection).

After this PR merges, release-please should open a fresh `chore(master): release 1.0.0` PR. Merging that will create the v1.0.0 tag, which will fire `release.yml`, which will build + attest + un-draft the release.

Test plan

  • `configure_github_repo.py plan` shows only the tag ruleset change; applied live.
  • Ruleset GET now shows Integration bypass with actor_id 3342783.
  • Release-please rerun produces a fresh v1.0.0 release PR after this merges.
  • Merging that release PR produces an actual `v1.0.0` git tag.
  • `release.yml` completes all three jobs end-to-end.

Followup

The configure_github_repo.py script uses PATCH for ruleset updates, which returned 404 even with `admin:org` scope and repo admin. PUT to the same endpoint worked. Worth investigating separately; not blocking this PR.

🤖 Generated with Claude Code

Release-please merged the original v1.0.0 PR but failed to push the
actual git tag because the meigma-release-please App was not in the
tag ruleset's bypass list. That left master with manifest=1.0.0 and a
populated CHANGELOG.md, but no v1.0.0 tag and a stale "untagged" draft
release on GitHub.

This commit re-seeds the release-please state so the next run proposes
v1.0.0 fresh:

- repository-settings.toml: uncomment the App bypass for the tag
  ruleset, expressed as type="integration" with the explicit App ID
  (3342783) so the configure script works without App-authorized
  tokens. Intent comment preserved above.
- .release-please-manifest.json: revert "." back to 0.0.0.
- CHANGELOG.md: delete; release-please will regenerate it.

Live state already updated: ruleset bypass pushed via configure
script; draft v1.0.0 release deleted; release-please's v1.1.0 PR (#14)
closed; autorelease:tagged label stripped from merged PR #9.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jmgilman
jmgilman merged commit b31b4a7 into master Apr 23, 2026
4 checks passed
@jmgilman
jmgilman deleted the session-007/reset-v1.0.0-release branch April 23, 2026 03:45
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.

1 participant