Usage without pull request

[JakeGinnivan]

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?

[Andarist]

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]

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

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:

[Andarist]

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 🤔

[JakeGinnivan]

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]

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

[jamsinclair]

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:

1. Commit with changeset file is merged to the main branch
2. CI is invoked and triggers the changeset action
3. Changesets reads the changeset files and git tags to determine which packages need publishing and their new version
4. New git tags are created for new versions
5. 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.

[mike-engel]

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.

[quantizor]

I'd definitely like a way to autorelease patches from the github action.

[JamilOmar]

here is an auto publish action https://github.com/JamilOmar/autopublish-changesets-action

[lachlancollins]

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: 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/checkout@v5.0.0
        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/action@v1.5.3
        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 }}