Why does semantic-version always return the same version number?

[Rod-at-DOH]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

I'm trying to get a new semantic version to apply when creating a new tag/release. I thought that paulhatch/semantic-version and softprops/action-gh-release would work. But every time I run the workflow I've made for it, it always gets the same semantic version number and applies it over and over again. In this case semantic version number v1.0.3. What am I doing wrong? Here's the YAML:

name: Semantic Versioning Workflow

on:
   workflow_dispatch: # manual
    
jobs:
    Find-Version-Numbers:
        runs-on: self-hosted
        steps:
            - name: Checkout files
              uses: actions/checkout@v6
              with:
                  fetch-depth: 0 # Fetch all history for all branches and tags
            - name: Determine semantic version
              id: tagger
              uses: paulhatch/semantic-version@v5.4.0
              with:
                  tag_prefix: 'v'
                  major_pattern: 'MAJOR'
                  minor_pattern: 'MINOR'
                  version_format: '${major}.${minor}.${patch}'
            - name: Print Semantic Version
              run: |
                echo "Semantic Version: ${{ steps.tagger.outputs.version }}"

            - name: Run Action-GH-Release
              uses: softprops/action-gh-release@v2
              with:
                tag_name: v${{ steps.tagger.outputs.version }}
                name: Release ${{ steps.tagger.outputs.version }}
                body: "Automated release created by Semantic Versioning Workflow."

[Gecko51]

Two things are going on.

First, how paulhatch/semantic-version actually works. It looks at the latest tag matching your tag_prefix, then counts commits since that tag to compute patch, and counts commits matching minor_pattern / major_pattern since the last minor or major bump. If you manually dispatch the workflow twice without any new commit landing on the branch in between, the action sees the same commit graph and returns the same version. So the first gotcha: a new version requires new commits. Re-running the same workflow on the same HEAD won't bump anything.

Second, the self-hosted runner part is probably biting you. actions/checkout on self-hosted keeps the workspace between runs by default. fetch-depth: 0 fetches history but it doesn't always prune or re-fetch tags that were created by a previous run (especially when the tag was pushed from the same runner by softprops/action-gh-release). The action then reads the stale "last tag" state and recomputes against it.

Try this:

- name: Checkout files
-   uses: actions/checkout@v4
-   with:
-     fetch-depth: 0
-     fetch-tags: true
-     clean: true
- name: Make sure tags are fresh
-   shell: bash
-   run: |
-     git fetch --tags --force --prune
-     git tag --list 'v*' --sort=-v:refname | head -5
- ```
Keep that `git tag --list` step for a few runs, it tells you exactly which tag paulhatch treats as the baseline. If it keeps showing `v1.0.2` when you expect `v1.0.3` to be there, the release step from the previous run didn't actually push the tag. Check that the workflow has `permissions: contents: write` at the job or workflow level, otherwise `softprops/action-gh-release` fails to create the release and tag.

Side note: `actions/checkout@v6` isn't a real tag, the current stable is `v4`. That was probably a typo.

Last thing, your patterns match the literal strings `MAJOR` and `MINOR` in commit messages. If none of your commits contain those words you'll never bump past patch, which is often how people end up stuck at `v1.0.x`. Conventional commits with matching patterns (like `^feat:` for minor, `BREAKING CHANGE` for major) tends to be cleaner.

Drop the workflow run log here if it's still stuck after the tag-fetch fix.

[Rod-at-DOH]

Thank you for this information! I had some YAML code which I commented out, to cause the workflow to run upon a PR to the default branch. When uncommented the code, then I discovered the semantic-versioning worked as expected. I didn't realize that commented that code out was causing my problem.