outputs.version is set only if commit is true #94

Activity

1. woile commented on Dec 21, 2024

   

   woile

   on Dec 21, 2024

   Member

   More actions

   Is that how you access outputs.version? Looking at the script, the version is inserted even with push: false, commit:false, so it should work.
2. Clockwork-Muse commented on Dec 23, 2024

   

   Clockwork-Muse

   on Dec 23, 2024

   Author

   More actions

   With the following workflow:

   name: Version Bump
   concurrency:
     group: bump
   
   on:
     push:
   
   jobs:
     bump:
       runs-on: ubuntu-latest
       env:
         CHANGELOG_INCREMENT_FILENAME: ${{ github.workspace }}/INCREMENT.md
       steps:
         - name: Checkout code
           uses: actions/checkout@v4
           with:
             fetch-depth: 0
   
         - id: bump
           name: Create bump and changelog
           uses: commitizen-tools/commitizen-action@master
           with:
             push: false
             commit: false
             changelog_increment_filename: ${{ env.CHANGELOG_INCREMENT_FILENAME }}
   
         - id: envprint
           name: Print Env
           run: |
             printenv
             echo "Step Output: ${{ steps.bump.outputs.version }}"
   
         - id: release
           name: Create release
           if: steps.bump.outputs.version != env.PREVIOUS_REVISION
           run: |
             echo "${{ steps.bump.outputs.version }}"

   The job output shows the following environment variable/output (truncated for brevity):

   PREVIOUS_REVISION=0.1.0
   REVISION=0.1.0
   Step Output: 0.1.0

   Additionally, the release job is skipped.

   The generated changelog does show the bump, but none of the outputs reflect that:

   ## 0.1.1 (2024-12-23)
   
   ### Fix
   
   - **test**: check for bump update
   
   ## 0.1.0 (2024-12-09)
3. Cynocracy commented on Jan 22, 2025

   

   Cynocracy

   on Jan 22, 2025

   More actions

   I can reproduce this, unable to use commitizen-action to bump the semver without commit: true
4. g-a-c commented on Feb 3, 2025

   

   g-a-c

   on Feb 3, 2025

   More actions

   I can reproduce this also. I suspect this is because when nothing is committed, the bump is detected correctly (for example 0.0.0 -> 0.1.0 in my test repo) but then the version comes from cz version --project which still returns 0.0.0 because the commit doesn't exist and nothing exists in the repo to refer to that version bump.

   I can see a couple of potential fixes for this:

   • when commit: false use the --get-next functionality, which reduces the output from cz bump into a short string which is suitable for consumption in a variable

     • $ cz bump --yes --files-only
       bump: version 0.0.0 → 0.1.0
       tag to create: 0.1.0
       increment detected: MINOR

       vs

       $ cz bump --yes --files-only --get-next
       0.1.0

   • do something with post_bump_hooks and the CZ_POST_ environment variables which appear to be set by Commitizen regardless of the outputs, and unlike calling a new cz version --project command should use the correct version as correctly determined by cz bump
     • for example a post_bump_hook of echo "version=${CZ_POST_CURRENT_VERSION}" >>"$GITHUB_OUTPUT"

   I'm looking to build a workflow where commits to main are forbidden by company policy - so all I need Commitizen to do is use conventional commits to determine what the next version should be based on the contents/scope, and then tell me what the tag would be so that I can then use a second GitHub Action to create a GitHub release (including a Git tag, and changelogs as part of the release and not a CHANGELOG file in a commit). I'm keen to see how this could be fixed because apart from this bug Commitizen does seem to be able to do what I need.
5. g-a-c commented on Feb 3, 2025

   

   g-a-c

   on Feb 3, 2025

   More actions

   For the folk still having this issue, I'm curious whether changing the reference to g-a-c/commitizen-action@feature/commit-false-fix works for you? I've used this fork and I've successfully run this against a Git repo with zero existing tags and found that both the "bump" from 0.0.0 -> 0.1.0 is detected successfully and also the tag gets created correctly as 0.1.0
6. bearomorphism commented on May 10, 2026

   

   bearomorphism

   on May 10, 2026

   More actions

   Reproduced and fix posted as #114.

   Repro (fresh repo, one feat: commit, version_provider = ""scm"", commit: false):

   PREV_REV=0.0.0
   bump: version 0.0.0 → 0.1.0
   tag to create: 0.1.0
   increment detected: MINOR
   Post-bump: cz version --project = '0.0.0'
   === outputs ===
   version=0.0.0
   next_version_major=0
   next_version_minor=0
   

   Cause: outputs.version is sourced from cz version --project after the bump. With version_provider=""scm"" + commit:false, the bump does not update any tracked file and does not create a tag, so cz version --project keeps reporting the old version.

   Fix in #114: capture the would-be next version with cz bump --get-next before the real bump (a pure computation, no state change), and use it as a fallback when cz version --project still reports the previous version after the bump. Major/minor are derived from the same captured string so they stay consistent. The fallback is skipped when --get-next itself fails (e.g. no bumpable commits), preserving today's behaviour.

   After fix:

   === outputs ===
   version=0.1.0
   next_version_major=0
   next_version_minor=1
   
7. bearomorphism

   added a commit that references this issue on May 10, 2026

   fix: report new version when commit is false and no version files update

   ...

   This issue will close once commit b83b888 is merged into the 'master' branch.

   b83b888