outputs.version is set only if commit is true

[Clockwork-Muse]

I have a workflow where I'm relying solely on the git history for version updates (no file changes).
You can turn off any file updates or other git changes by writing:

- id: bump
  name: Create bump
    uses: commitizen-tools/commitizen-action@master
    with:
      push: false
      commit: false

... and you get the expected output:

cz --no-raise 21 bump --yes --changelog --files-only
bump: version 0.0.0 → 0.1.0
tag to create: 0.1.0
increment detected: MINOR

Repository: someorg/somerepo
Actor: clockwork-muse
Not pushing
Done.

Unfortunately, this doesn't update outputs.version, leaving it at the previous version (0.0.0). This means I have to set commit: true, which disturbs the in-runner git state, which slightly complicates creation of releases (although in all honesty I probably should have done that anyways...).

[woile]

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.

[Clockwork-Muse]

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)

[Cynocracy]

I can reproduce this, unable to use commitizen-action to bump the semver without commit: true

[g-a-c]

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.

[g-a-c]

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