Skip to content

Release flow: tag-triggered publish + release-it config#2

Open
shipstatic-com wants to merge 2 commits intomainfrom
release-flow
Open

Release flow: tag-triggered publish + release-it config#2
shipstatic-com wants to merge 2 commits intomainfrom
release-flow

Conversation

@shipstatic-com
Copy link
Copy Markdown
Contributor

Why

Per n8n's community-node verification process, the recommended pattern is to use a release tool (n8n-node release / release-it) so the code repo and npm stay in sync and every release has notes. Our current npm-publish.yml auto-publishes on every push to main with no tag, no GitHub Release, and no test/lint gate — none of which n8n's guideline-check has visibility into.

This PR switches us to the recommended pattern with minimal change.

How it works after this PR

pnpm run release      ← local: release-it bumps version, commits, tags,
                        pushes, creates GitHub Release with auto-notes

→ tag push (v*) triggers npm-publish.yml in CI
→ CI runs lint + test + build + pnpm publish --provenance
→ Slack ping on success/failure

The local release script invokes the existing release-it (already in devDeps). The CI's only job is the npm publish itself, in a clean environment, gated by lint+test.

What's in this PR

.github/workflows/npm-publish.yml

  • Trigger changed from push: branches: [main]push: tags: ['v*']
  • Added pnpm lint + pnpm test --run steps before publish (real CI guardrails — previously the workflow could publish a regression)
  • pnpm install --frozen-lockfile for reproducible builds

.release-it.json (new)

  • Tag format v${version} (matches existing convention)
  • Require main branch + clean working dir (safety)
  • github.release: true with autoGenerate: true — release notes from commits/PRs since the previous tag
  • npm.publish: false — the CI workflow is the single source of truth for the publish artifact
  • Hooks: lint+test before init, build after version bump

Effect on the next release

  • The 0.7.0 PR (v0.7.0: Resource Locator + DNS/Share + polish #1) currently merges to main and does NOT auto-publish under this new flow (no tag = no publish). To ship 0.7.0, after that PR merges:
    git checkout main && git pull
    pnpm run release   # release-it prompts for version, defaults to next bump
    
    release-it handles the rest. CI sees v0.7.0 tag → publishes.

Verification

  • Workflow YAML valid
  • release-it.json matches release-it@19 schema
  • No code changes — purely release infrastructure

Test plan

  • Merge this PR
  • Merge the 0.7.0 PR (v0.7.0: Resource Locator + DNS/Share + polish #1) — confirm CI does NOT auto-publish (new trigger filters branch pushes out)
  • Run pnpm run release locally from main → confirm version bump, tag, GitHub Release with notes
  • Confirm CI fires on the tag push and publishes 0.7.0 to npm with provenance

Switch the release process from "auto-publish on push to main" to
"release-it locally → tag-triggered CI publish". This brings the package
in line with n8n's verification expectations: code repo and npm stay in
sync, and every release has notes.

Workflow (.github/workflows/npm-publish.yml):
- Trigger on tag push (`v*`) instead of branch push to main
- Add `pnpm lint` + `pnpm test --run` gates before publish (real CI guardrails)
- Use `pnpm install --frozen-lockfile` for reproducible builds

Release-it config (.release-it.json):
- Tag format `v${version}` to match existing convention
- Require `main` branch + clean working dir (safety)
- Create GitHub Release with auto-generated notes from commits/PRs
- Skip npm publish from local — CI handles it on tag push (single source
  of truth for the publish artifact, built in a clean environment)
- Hooks: lint+test before init, build after version bump

How releases work now:
  pnpm run release      # local: bump → commit → tag → push → GitHub Release
  → tag push triggers Action → lint + test + build + npm publish
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