Repository navigation
Usage without pull request #77
Description
Activity
What is the overall workflow that you are trying to achieve? Should each merge to your base branch with at least one changeset result in an additional commit and immediate version bumps? 🤔
Reacted by JonathanYep, that is what I am going for. Release new packages as soon as the PR is merged
This is the workflow I ended up creating
jobs: version: runs-on: ubuntu-latest outputs: changes: ${{ steps.version.outputs.changes }} # map step output to job output steps: - name: Checkout uses: actions/checkout@master with: # This makes Actions fetch all Git history so that Changesets can generate changelogs with the correct commits fetch-depth: 0 token: ${{ secrets.SERVICE_ACCOUNT_PAT }} - name: Enable node uses: actions/setup-node@master with: node-version: 14.x registry-url: 'https://registry.npmjs.org' scope: '@wanews' env: NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} - name: Install pnpm run: | npm i -g pnpm pnpm set verify-store-integrity false - name: pnpm install run: | pnpm install --frozen-lockfile - name: Version command id: version run: | echo ::set-output name=changes::$(pnpx changeset version 2>&1 | grep -q 'No unreleased changesets found' && echo 'false' || echo 'true') - name: Push changes if: steps.version.outputs.changes == 'true' run: | git config user.email "github.serviceaccount@" git config user.name "GitHub Service Account" git add -A git commit -m "Version packages" || echo "No changes to commit" git push build: runs-on: ubuntu-latest needs: version if: always() && needs.version.outputs.changes == 'false' steps:What about possible race conditions when merging stuff to your base branch in quick succession? It seems that this can easily amplify the problem 🤔
I'm wondering - is your action from the comment above pushing to the base branch? The version command in our actions switches to the
versionBranchand I don't see you switching back to the base branch 🤔I really wish GitHub actions had a way to serialize certain builds. There are a few different race conditions.
If there was a race condition I use git as the lock in the above, one of the builds would fail because they would not be able to push I think
What is the overall workflow that you are trying to achieve? Should each merge to your base branch with at least one changeset result in an additional commit and immediate version bumps? 🤔
Yeah, but not for base branch for next branch for doing pre-releases without having to merge them manually
What about possible race conditions when merging stuff to your base branch in quick succession? It seems that this can easily amplify the problem 🤔
@Andarist now that some time has gone past, how would you feel about experimenting with a flow without the pull request?
The main issue you validly raise is the extra commits and git conflicts that could come from versioning in an automatic flow. Semantic-Release solved this by being able to track versions in git tags only, which we already have in available in
changesets😏 .I'm not too familiar with the codebase, but suppose the biggest refactor/change is adding the logic to only track versions by git tags.
I imagine the flow for a changeset user would be:
- Commit with changeset file is merged to the main branch
- CI is invoked and triggers the changeset action
- Changesets reads the changeset files and git tags to determine which packages need publishing and their new version
- New git tags are created for new versions
- Triggers publish command and publishes affected packages
☝️ Note that no commits are necessary, users would leave their package versions in code at likely
0.0.0-automatically-versioned.I'd be happy to help explore some of this 🤓 , I think of a lot of teams are torn between semantic-release and changesets. Having an automatic flow would be a huge benefit for teams looking to migrate.
The
concurrencykey would be recommended for GitHub Actions to prevent race conditions.From our side, we also usually have a
workflow_dispatchworkflow that would be run manually when ready to publish. Being able to version and publish without creating a PR is what we would need here (and what I'll probably create by hand), and the race condition issue isn't a problem here because the workflow is run manually. We're a small team publishing internal packages only, so we don't have many releases.I'd definitely like a way to autorelease patches from the github action.
Reacted by jacksonneal, Pooyan Razian and Benoît Rouleauhere is an auto publish action https://github.com/JamilOmar/autopublish-changesets-action
Reacted by Pavindu LakshanHere's a solution I've come up with for TanStack Query. It still makes full use of the changesets action, meaning it handles all the GitHub releases/tagging/commiting, which is trickier to achieve without the action. It uses a repository dispatch to automatically merge the release PR for patch/minor changes - major changes still require manual merge.
name: Release on: push: branches: [main] repository_dispatch: types: [release] permissions: contents: write id-token: write pull-requests: write jobs: release: name: Release runs-on: ubuntu-latest steps: - name: Checkout uses: actions/[email protected] with: fetch-depth: 0 # Do your setup/installation/tests here - name: Check for Changesets marked as major id: major run: | echo "found=false" >> $GITHUB_OUTPUT regex="(major)" shopt -s nullglob for file in .changeset/*.md; do if [[ $(cat $file) =~ $regex ]]; then echo "found=true" >> $GITHUB_OUTPUT fi done - name: Run Changesets (version or publish) id: changesets uses: changesets/[email protected] env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} NPM_TOKEN: ${{ secrets.NPM_TOKEN }} - name: Auto-merge Changesets PR if: steps.changesets.outputs.hasChangesets == 'true' && steps.major.outputs.found == 'false' run: | gh pr merge --squash "$PR_NUMBER" gh api --method POST /repos/$REPO/dispatches -f 'event_type=release' env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} REPO: ${{ github.repository }} PR_NUMBER: ${{ steps.changesets.outputs.pullRequestNumber }}
- marked Shortcut "Version Packages" PR via special "commit commands" #162 as a duplicate of this issue
on May 15, 2026 - marked Auto merge / skip the automatic PR process #310 as a duplicate of this issue
on May 15, 2026
Hey team,
I was just wondering if you had objections to a flag being passed which versioned direct on master (without going through the PR workflow).
The workflow I am thinking about has 2 jobs, the first simply runs changeset actions. If it versions any packages the second job will not run, the push would trigger master again which would release.
Otherwise I guess the manual way is to run
changeset version, look for the warn that there are no packages to publish, then that is the flag to continue to next job?