Skip to content

test: promote staging to main to trigger 1.1.0 release - #381

Merged
codewizdave merged 3 commits into
mainfrom
test/staging-to-main
Aug 3, 2026
Merged

test: promote staging to main to trigger 1.1.0 release#381
codewizdave merged 3 commits into
mainfrom
test/staging-to-main

Conversation

@martyy-code

Copy link
Copy Markdown
Contributor

Summary

Promotes the contents of staging to main to finalize the e2e test of the refactored release pipeline (PR #380). This PR brings into main the changeset release-1.1.0.md that was previously merged into staging.

Why

The refactored release pipeline (publish.yml after PR #380) triggers on pull_request: closed (merged) on main. The new job detects whether the merge commit introduced changeset files, and if so, bumps the version, publishes to npm via Trusted Publishing, creates a git tag, and creates a GitHub Release — all in one run.

The changeset for the 1.1.0 release is currently on staging. To trigger the new pipeline, the changeset needs to land on main. This PR is the staging-to-main promotion that does so.

What happens on merge

  1. The merge commit fd36b5a (the head of staging) lands on main.
  2. The release workflow runs.
  3. Step "Detect changesets" computes the diff HEAD~1..HEAD of the merge. It finds .changeset/release-1.1.0.md (added).
  4. has_changesets = true → the rest of the job proceeds.
  5. pnpm changeset version bumps @deessejs/fp from 1.0.2 to 1.1.0.
  6. The bot commits the version bump to main and pushes.
  7. pnpm build, pnpm test, smoke test.
  8. Anti-republish guard: queries npm for 1.1.0 → does not exist → proceed.
  9. pnpm changeset publish --tag latest publishes @deessejs/fp@1.1.0 via Trusted Publishing, with provenance attestation.
  10. The bot creates and pushes the tag v1.1.0.
  11. softprops/action-gh-release creates the GitHub Release for v1.1.0.

What is being tested

This PR is the e2e validation of the refactored release pipeline. After it merges:

  • npm @deessejs/fp@latest should advance from 1.0.2 to 1.1.0.
  • The tag v1.1.0 should exist on main.
  • A GitHub Release for v1.1.0 should be created with auto-generated notes.
  • The provenance attestation should be visible on the npm package page.

Test plan

  • pnpm turbo type-check passes.
  • pnpm turbo lint passes.
  • Merge → release workflow runs → all steps green → npm publishes 1.1.0 → tag + GitHub Release created.

Risk

Low. This PR is a fast-forward from staging. No new content beyond what is already reviewed on staging. The release pipeline has not yet been exercised end-to-end with this refactored design, so a publish failure is possible (revert the merge commit if so).

Rollback

Revert the merge commit on main. The 1.1.0 published on npm can be npm unpublish-ed within 72h. The tag and GitHub Release can be deleted manually.

🤖 Generated with Claude Code

release-pipeline-test and others added 3 commits August 3, 2026 17:23
Triggers Changesets to bump @deessejs/fp from 1.0.2 to 1.1.0
when the next Version Packages PR is opened on staging.

This advances the published npm version past the dummy
release-test artifact (1.0.2) and produces the first legitimate
minor bump since the Trusted Publishing migration.
Observed on the 1.0.2 dummy release run (30817274927): the tag
push step in publish.yml failed with HTTP 403 because the
GitHub tag protection rule on 'v*' blocked the
github-actions[bot] push. The bot is not an allow-listable actor
on tag protection rules — only users, teams, GitHub Apps, and
roles are.

§4 previously recommended enabling a tag protection rule on v*
with an empty allow-list. That recommendation is wrong for any
pipeline that uses GITHUB_TOKEN to push tags. The correct
senior pattern, used by @deessejs/errors in this same repo and
by Vite/Vue/Nuxt/Cloudflare SDK in production, is to skip tag
protection entirely and rely on:

- environment 'release' as the human gate
- anti-republish guard as the no-double-publish check
- OIDC provenance as the audit trail
- branch protection on main as the gate on direct pushes

§4 rewritten to document this decision and explain why tag
protection is intentionally absent.

No code changes.
chore: 1.1.0 release (advance past 1.0.2 dummy)
@codewizdave
codewizdave merged commit 04e3798 into main Aug 3, 2026
4 of 5 checks passed
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.

2 participants