You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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? 🤔
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 versionBranch and I don't see you switching back to the base branch 🤔
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 concurrency key would be recommended for GitHub Actions to prevent race conditions.
From our side, we also usually have a workflow_dispatch workflow 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.
Here'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: Releaseon:
push:
branches: [main]repository_dispatch:
types: [release]permissions:
contents: writeid-token: writepull-requests: writejobs:
release:
name: Releaseruns-on: ubuntu-lateststeps:
- name: Checkoutuses: actions/[email protected]with:
fetch-depth: 0# Do your setup/installation/tests here
- name: Check for Changesets marked as majorid: majorrun: | 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: changesetsuses: changesets/[email protected]env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
- name: Auto-merge Changesets PRif: 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 }}
Activity
Andarist commentedon Mar 22, 2021
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? 🤔
JakeGinnivan commentedon Mar 23, 2021
Yep, 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
Andarist commentedon Mar 23, 2021
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 🤔JakeGinnivan commentedon Mar 29, 2021
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
akshayr20 commentedon Jul 30, 2021
Yeah, but not for base branch for next branch for doing pre-releases without having to merge them manually
jamsinclair commentedon Aug 31, 2022
@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:
☝️ 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.mike-engel commentedon May 11, 2023
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.quantizor commentedon Jun 21, 2023
I'd definitely like a way to autorelease patches from the github action.
JamilOmar commentedon Jan 23, 2024
here is an auto publish action https://github.com/JamilOmar/autopublish-changesets-action
lachlancollins commentedon Oct 2, 2025
Here'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.