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