zwaldowski / semver-release-action

Create the next semantic version and tag it.
MIT License
37 stars 23 forks source link

Using example from README still not working. #2

Open mcpierce opened 4 years ago

mcpierce commented 4 years ago

(opening this since you closed the other ticket before we got to a solution)

Overview/Goal For our project, we would like each checking on the develop branch to automatically increment the prerelease version and tag the commit with that updated version. We're currently wanting to use "X.Y.Z.n" to be the major, minor, patch and prerelease version elements (though we will change that scheme to suit whatever tool does the increments for us).

Attempted Solutions I took the example from the README file and applied it to my project's workflow (see example YML below).

Outcome When I pushed the updated workflow file I continued to get the following error message (even after following the developer's suggestion for changing the workflow):

Screen Shot 2019-11-25 at 12 26 58 PM

Desired Response I'm asking for the developer on this Github Action to provide a cogent example for doing the above, and to add it to a recipe for using his action that other project's can use as a guide.

tag-develop-commits.yml

name: Incremental development release tagging

on:
  push:
    branches:
      - develop

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - id: bump
        name: Determine version increment
        uses: zwaldowski/match-label-action@v1
        with:
          bump: prerelease
          allowed: major,minor,patch,prerelease
      - name: Release version
        uses: zwaldowski/semver-release-action@v1
        with:
          bump: ${{ steps.bump.outputs.match }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
zwaldowski commented 4 years ago

The example in the README uses a separate action to determine the kind of version bump to make. You can get the string major, minor, patch, prerelease any way you want.

Using zwaldowski/match-label-action is just one way. That action looks for a corresponding label on a pull request. You appear to have not applied a corresponding label to your pull request, or are not using a pull request workflow.

Either apply a corresponding label to a PR before you merge it, or find some other action to get you the string major, minor, patch, prerelease to pass into this action. For example, you may find an action that looks at commit messages, branch names, and so on.

If you want to use a pull request workflow with zwaldowski/match-label-action, you may find it useful to require these labels before merging is allowed. That would be a separate workflow that runs on pull requests instead of pushes. You can find an example of such a workflow here.