Skip to content

ci(release): publish on tag push, not only on GitHub Release - #15

Open
laynepenney wants to merge 1 commit into
mainfrom
chore/tag-triggered-publish
Open

ci(release): publish on tag push, not only on GitHub Release#15
laynepenney wants to merge 1 commit into
mainfrom
chore/tag-triggered-publish

Conversation

@laynepenney

Copy link
Copy Markdown
Member

What

Adds a push: tags: ['v*'] trigger to publish-pypi.yml and publish-npm.yml so a tag push publishes — the "publish via tag on gh" mechanism Layne asked for. Additive: the existing release: [published] path stays, so gh release create <tag> still works (and still uploads the SBOM to the release).

Why it's safe

Idempotent double-fire: gh release create v0.1.0 fires both the tag-push and the release event. PyPI's skip-existing: true and npm's existing "already published → skip" check make the second attempt a no-op. Trusted publishing (OIDC, environment: pypi, id-token: write) is untouched — it binds to the workflow file + environment, not the trigger, so changing the trigger doesn't affect auth.

Two things for synapt-side review (flagged, not decided by me)

  1. No tag↔version guard, on purpose. A strict tag == package version assertion would prevent a mistagged publish, but this repo's version-sync-deferred design (per the publish-npm.yml comment) allows PyPI and npm versions to diverge. A guard would fight that. Whether/how to guard the tag↔version relationship is a synapt versioning-convention call — left to you.
  2. PyPI trusted-publisher must be registered for the publish to authenticate: repo synapt-dev/eval, workflow publish-pypi.yml, environment pypi. If it was added as a pending publisher when the project was created, it activates on first publish; if not, the first run fails OIDC auth. Worth confirming before the first tag.

First real tag push is the SACRED first publish — Layne's / a coordinated moment.

Add a 'push: tags: [v*]' trigger to both publish workflows so a tag push
publishes to PyPI and npm, in addition to the existing 'release: published'
path. Additive and idempotent — a 'gh release create <tag>' that fires both
events is safe: PyPI skip-existing and the npm already-published check no-op
the second attempt.

Deliberately NOT adding a tag<->package-version guard: this repo's
version-sync-deferred design allows the PyPI and npm versions to diverge, so a
strict tag==version assertion would fight that design. Flagged for synapt-side
review (see PR body).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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