Adds option to only allow commits from a specific path to trigger the release

[josejulio]

This restrict the commits that are inspected to only the ones that have the specific path.

My use-case is the following:

I'm managing a mono-repo which has two packages: package-1 and package-2. What I want to accomplish is to avoid "BREAKING CHANGE" commits of package-1 to increase the major version of package-2. As a bonus, this would also prevent releases from package-1 when the commits only touched package-2 files.

- uses: mikeal/merge-release@master
  env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}
      DEPLOY_DIR: packages/insights-common-typescript
      SRC_PACKAGE_DIR: packages/insights-common-typescript
      ALLOW_PATH: packages/insights-common-typescript

[josejulio]

@mikeal wondering if this is something that you would like to get in, or if you need more information on the use-case. If so, I would rebase and proceed.

Thanks!

[mikeal]

Sorry, I hadn’t seen this come in and just got around to reviewing it.

I’m a little concerned with this. First of all, that’s a lot of code now in the try block, any number of errors will now cause it to skip releasing.

Also, I’m wondering why this would be the preferred behavior rather than using github action filters to not run the action at all unless certain files are changed?

[josejulio]

Also, I’m wondering why this would be the preferred behavior rather than using github action filters to not run the action at all unless certain files are changed?

Ah, I didn't know about that possibility: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-including-paths

Looks like that's the way to go, thanks!

[josejulio]

Also, I’m wondering why this would be the preferred behavior rather than using github action filters to not run the action at all unless certain files are changed?

I got in a situation today that these changes would be valid/useful.

I have some packages on a monorepo that I want to release independently, so I have one workflow for each. The thing is that I pushed some code that affected the package and the workflow. There was an error in release-workflow and the package didn't got published. My only options now are:

a) Manual release b) Push some dummy changes to trigger the release workflow again

Something like this is useful in that scenario as I could fix the workflow and push again, besides I could define an env for the path and that would save me having workflow per package.

Thoughs @mikeal ?