chore(modal): sync version, broaden release filter, skip empty publishes#192
Merged
Conversation
- Bump packages/modal/package.json to 7.0.1 to align with what was actually published to npm during the 7.0.1 ship (the git push to main was blocked by branch protection, fixed in #186 via GH_PAT). Without this, the next release-it run would compute its base from 7.0.0 and try to re-publish 7.0.1 (403 duplicate). - Prepend a 7.0.1 entry to CHANGELOG.md describing the CI sync. - Loosen .release-it.js commitFilter to also count any commit with a BREAKING CHANGE note, in addition to (modal)-scoped commits. This ensures unscoped feat!/fix! or commits with a BREAKING CHANGE footer still trigger a release, while unrelated chore/deps noise is ignored.
There was a problem hiding this comment.
Pull request overview
This PR synchronizes the modal package release metadata with the already-published 7.0.1 version and broadens release detection so modal releases are triggered by scoped commits or breaking-change notes.
Changes:
- Bumps
packages/modalversion from7.0.0to7.0.1. - Adds a
7.0.1changelog entry documenting the release workflow/cache fix and version alignment. - Updates the release-it
commitFilterto include(modal)commits and commits withBREAKING CHANGE/BREAKING-CHANGEnotes.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
packages/modal/package.json |
Aligns package version with published npm version. |
packages/modal/CHANGELOG.md |
Prepends the 7.0.1 changelog entry. |
packages/modal/.release-it.js |
Broadens conventional-changelog commit filtering for release bump detection. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
5 tasks
GSTJ
added a commit
that referenced
this pull request
May 19, 2026
…195) ## Summary Fixes two bugs in the `🚀 Publish` workflow that combined to cause an unintended publish (and then a failed `git push` to main) on every push. ### Issue 1 — skip probe always proceeded The probe ran `release-it --release-version --ci --no-npm --no-github` and grepped its stdout for the next version. When no commits matched the `(modal)` scope filter, the conventional-changelog plugin returned no recommendation; release-it's Version plugin then fell back to its CI default of `patch(latestVersion)`. Because there is no `magic-modal-*` git tag yet, `latestVersion` was `0.0.0`, so the probe printed `0.0.1`. `0.0.1 != 7.0.1` → the skip check proceeded → release-it bumped to `7.0.2` and published. Replaced with a deterministic git-history probe: 1. Boundary = most recent of: last `magic-modal-*` tag, last `chore(release):` commit, last `chore(modal): sync version` commit. 2. `git log <boundary>..HEAD` filtered by `(modal)` scope or `BREAKING CHANGE` footer (mirrors the `commitFilter` in `.release-it.js`). 3. Zero matches → `skip=true`. Verified locally on current `main`: boundary correctly resolves to `08d293e` (the #192 sync commit) and `skip=true`. ### Issue 2 — `GH_PAT` push denied The `🚀 Release` step failed with `Permission to GSTJ/react-native-magic-modal.git denied to GSTJ` when release-it tried to push the version-bump commit back to main. The PAT (vintage 2024) is no longer accepted by branch protection. Set `git.push: false` in `packages/modal/.release-it.js`. `commit` and `tag` stay `true` so the `@release-it/github` plugin still has a local tag to bind the GitHub Release to on the runner. The version bump is now runner-local only; sync to `main` via a follow-up PR when needed (same pattern as #192). `TODO` comment left in the config to re-enable `push` once `GH_PAT` is rotated with `contents: write` + branch-protection bypass. Also added `fetch-depth: 0` to the checkout so the probe can see full history. ## Test plan - [x] Probe locally returns `skip=true` on current `main` (no qualifying commits since the #192 sync) - [x] Probe logic mentally verified for the `feat(modal):` case — `git log` grep matches → `skip=false` - [x] `pnpm typecheck` passes - [x] `actionlint` passes structurally (only pre-existing SC2086 warnings, unrelated) - [ ] On merge to main, the Publish workflow either (a) skips cleanly because nothing qualifies, or (b) when something does qualify, publishes to npm + creates a GitHub Release without trying to push back to main
GSTJ
added a commit
that referenced
this pull request
May 19, 2026
The skip probe in `release.yml` (added in #195) used `git log --grep` which scans the entire commit message body. The squashed PR description for #195 mentioned `BREAKING CHANGE` in its explanation prose, which falsely matched the regex → skip=false → release-it bumped to 7.0.2 and tried to publish. Net effect: 7.0.2 got published (npm has it), then the workflow died on git push permission. Workflow status: red on main. ## Fix Replace `git log --grep` with explicit per-commit (subject, body) iteration using ASCII unit/record separators. Match `(modal)` only in the subject line, and require `BREAKING CHANGE:` (or `BREAKING-CHANGE:`) to start a body line — i.e. the actual conventional-commits footer form, not a mention in prose. Verified locally on `origin/main`: the merge commit of #195 is now correctly classified as non-qualifying. ## Expected behavior next push to main - This PR is `fix(ci):` (no `(modal)` scope, no `BREAKING CHANGE:` footer) - → boundary scan finds zero qualifying commits since #192 - → skip=true → workflow exits green
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three small fixes to unblock the release workflow:
Sync
packages/modal/package.jsonversion7.0.0→7.0.1— matches what's currently published on npm. The previous workflow run bumped the registry but the version-bump commit never landed onmain, so the repo drifted behind.Broaden
.release-it.jscommitFilterto also count any commit carrying aBREAKING CHANGEfooter (incommit.notes), regardless of scope. Previously only(modal)-scoped commits qualified, so an unscopedfeat!:/fix!:would never trigger a release.Skip the
🚀 Publishworkflow when there is nothing to release. A new🔎 Determine next versionstep runsrelease-it --release-version --ci --no-npm --no-githuband compares the candidate version againstpackage.json. If they match (or the probe yields no version), the actual release step is skipped viaif: steps.next-version.outputs.skip != 'true'. This prevents the workflow from going red with403 You cannot publish over 7.0.1when there are no new releasable commits.Test plan
pnpm typecheckpassespnpm exec release-it --release-version --ci --no-npm --no-githubreturns a parseable version locallymainwithout modal commits: workflow stays green and skips release stepmainwith a(modal)orBREAKING CHANGEcommit: workflow publishes as before