Skip to content

ci(release): publish every release automatically, with no stored token - #14

Merged
arosasg merged 3 commits into
mainfrom
chore/auto-publish-releases
Oct 29, 2026
Merged

ci(release): publish every release automatically, with no stored token#14
arosasg merged 3 commits into
mainfrom
chore/auto-publish-releases

Conversation

@arosasg

@arosasg arosasg commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

Problem

The 1.0.0 release (2026-10-29) needed manual steps: release-please ran only by hand, and a GitHub release created with the default GITHUB_TOKEN does not trigger the release: published event, so release.yml (the publish workflow) did not start. Alex asked that every future release publish straight from the repository.

Solution

  • release-please runs on every push to main (and by hand), so merging its release pull request cuts the release.
  • After creating a release, release-please starts release.yml for the new tag with gh workflow run, which GITHUB_TOKEN is allowed to trigger (actions: write). No personal access token is stored.
  • Node already publishes inside release-please.yml, so only the trigger and the header comment change.
  • The registries use trusted publishing (OIDC), so there is no publishing token to rotate. Stale "nothing may be published before 2026-11-01" comments are replaced: 1.0.0 is published.

Verification

  • actionlint on the changed workflows: no findings.
  • The trusted publisher on the registry is bound to release.yml and its environment, which a workflow_dispatch run keeps (the OIDC claims carry the same workflow file and environment).
  • After merge, the push run of release-please has no release to create, so nothing is published by this change itself.

🤖 Generated with Claude Code

@arosasg @claude
ci(release): publish every release automatically, with no stored token
fa9980d 
release-please now runs on every push to main, so merging the release pull
request creates the tag and the release. A release created with GITHUB_TOKEN
does not trigger the release event, so release-please starts release.yml for
the new tag with workflow_dispatch, which GITHUB_TOKEN may trigger. release.yml
accepts the tag as an input as well as the release event. Registries use
trusted publishing, so no publishing token is stored.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@arosasg

arosasg commented Oct 29, 2026

Copy link
Copy Markdown
Contributor Author

Codex review (codex CLI, account codex-7, model gpt-5.6-sol)

💡 Code review

Reviewed commit: fa9980d

P1 Badge Keep release tag creation behind explicit approval

.github/workflows/release-please.yml:L14-L15 - view

When a release PR is merged into main, this new push trigger immediately runs release-please and creates the release tag before the npm environment approval is reached. That violates the repository requirement that pushing a release tag needs Alex’s explicit approval, especially before 2026-11-01; retain a manual approval boundary before release-please can create the tag, not only before publishing.

AGENTS.md reference: AGENTS.md:L32-L32

Verdict: REQUEST CHANGES

@arosasg @claude
docs(release): releases publish straight from the repository
effd719 
Alex approved the 1.0.0 release on 2026-10-29 and asked that every release
publish straight from the repository. The pre-launch rule (no tag or publish
before 2026-11-01 without his approval) is replaced: merging the release-please
pull request is the release approval. docs/DESIGN.md section 13 records the
same, identically in all seven SDK repositories.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@arosasg

arosasg commented Oct 29, 2026

Copy link
Copy Markdown
Contributor Author

Codex review (codex CLI, account codex-2, model gpt-5.6-sol)

💡 Code review

Reviewed commit: effd719

P1 Badge Remove the second release approval gate

.github/workflows/release-please.yml:L56-L58 - view

When a release-please pull request is merged, this job enters the npm environment, which the retained comment requires to have a reviewer, so publishing pauses for another manual approval instead of treating the merge as the release approval. Remove that environment protection requirement (while retaining the environment if needed for OIDC or secrets) so the documented release flow completes automatically.

AGENTS.md reference: AGENTS.md:L32-L32

Verdict: REQUEST CHANGES

@arosasg @claude
docs(release): drop the pre-launch release policy everywhere
8f08063 
The SDK is released (1.0.0 on 2026-10-29) and merging the release pull request
is the release approval, so the leftover pre-launch text is replaced: the
README banners, the agent status line, the CONTRIBUTING release sections and
the workflow comments no longer describe a private, unreleased repository or a
reviewer gate on the publish environments (which have no required reviewers).
docs/DESIGN.md section 2.1 records the completed didit-sdk PyPI transfer and
the terms agreed with Agustin Saiz, identically in all seven repositories.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@arosasg

arosasg commented Oct 29, 2026

Copy link
Copy Markdown
Contributor Author

Codex review (codex CLI, account codex-7, model gpt-5.6-sol)

💡 Code review

Reviewed commit: 8f08063

No blocking findings in commit 8f08063.

Verdict: APPROVE

@arosasg
arosasg merged commit 9fb7c5d into main Oct 29, 2026
16 checks passed
@arosasg
arosasg deleted the chore/auto-publish-releases branch October 29, 2026 13:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@arosasg