Semantic version generator using git commit keywords and overrides

Hi!

Let me spend one line making an explicit thank you for sharing your knowledge and time in this project.

Now, to the issue:

I was testing your tool to incorporate it into our workflows. I found that the recently added existing: true flag, and also the strict flag don't work from the config file.

This is my config file:

version: 1
force:
  existing: true
  strict: true
wording:
  patch:
    - update
    - fix
  minor:
    - feature
    - improve
  major:
    - breaking
    - major
  release:
    - release-candidate
    - add-rc

I was originally testing directly from a Github Action:

name: Testing semver

on:
  push:
    branches:
      - main

jobs:
  prepare:
    name: Preparing build context
    runs-on: ubuntu-latest
    outputs:
      RELEASE_VERSION: ${{ steps.semver.outputs.semantic_version }}
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2
        with:
          fetch-depth: '0'
      - name: Semver run
        id: semver
        uses: lukaszraczylo/semver-generator@v1
        with:
          config_file: semver.yml
          repository_local: true
      - name: Semver check
        run: |
          echo "Semantic version detected: ${{ steps.semver.outputs.semantic_version }}"

The result was that existing tags were not taken into account, and strict mode didn't work either.

I download the project to test it locally and I realized that from my local computer I'm able to reproduce the same behavior running the binary in this way (semver.yml is the same one I included before):

./semver-gen generate -l  -c semver.yml
SEMVER 0.0.13

But if I run explicitly including the flags the result is the desired one:

./semver-gen generate -l -s -e -c semver.yml
SEMVER 0.1.0

Am I doing something wrong? Otherwise, I hope this requires minimal effort on your side since it's all I need for my workflows right now.

Thanks again.

During my tests when using the default config.yaml I noticed that minor keywords are acting as they were the patch ones.

It happened with add and change but NOT with improve.

config.yaml

version: 1
force:
  major: 1
  commit: 4dc131734b6e7504ebd185d70b5777059880ab59
wording:
  patch:
    - update
    - initial
    - fix
  minor:
    - add
    - change
    - improve
  major:
    - breaking

I got the following

Initially: 1.0.2
Breaking commit: 2.0.1
Change commit: 2.0.2
Update commit: 2.0.3
Improve commit: 2.1.1
Improve commit: 2.2.1
Add commit: 2.2.2

Describe the bug If installed using go it doesn't seem to work out of the box.

Output with debug semver-generator generate -l Unable to find config file semver.yaml

The default config.yaml is too generic and can be confused with other yaml files in the project. Maybe it would be better to have it more unique default name, like semver.yml, sem.yml or sem-version.yml

Describe the bug Tried to use this as part of a github action, but it failed without any output. It is unclear how to get debug output in this format. If it could work as described, this would absolutely fill a need for our project that I otherwise cannot find a plugin working for. If this is an issue with my configuration, please do let me know. I am also unsure if the "build semver-generator@v1" step at the beginning was truly successful or not, as it does have error output despite passing. Any help would be appreciated.

Output with debug (could not get debug output, as this is undocumented for github actions)

Expected behavior Expected action to succeed or show configuration issues.

Additional context The failed run: https://github.com/HDR-Development/HewDraw-Remix/runs/5252877868?check_suite_focus=true config file at this time: https://github.com/HDR-Development/HewDraw-Remix/blob/8da98b893e92979baebcc26d8e68257cbcfe3a47/.github/workflows/semver_config.yaml the action step: https://github.com/HDR-Development/HewDraw-Remix/blob/8da98b893e92979baebcc26d8e68257cbcfe3a47/.github/workflows/build.yml#L104

Manually updating the binary, after the "-v" flag was enabled can be troublesome. Add an additional flag which will trigger the update and replace the existing binary with the latest possible version.

Description:

Switch should trigger non zero exit if it fails to match any specified keywords for all the levels of version.

This should help teams operating on strict rules and naming conventions to avoid generation of unfinished work.

❯ semver-gen -v semver-gen 1.0.32

For

force:
  major: 0
  minor: 0
  patch: 0

❯ semver-gen generate -c config.yml -r https://github.com/hipertracker/words_extractor
SEMVER 1.4.12

which is correct, but for

force:
  major: 1
  minor: 1
  patch: 1

❯ semver-gen generate -c config.yml -r https://github.com/hipertracker/words_extractor
SEMVER 1.4.12

this is confusing. Should not force enforce the given 1.1.1 version incremented by all commits?

It increments a major number by 1 even when no new code commit was sent.

E.g for config.yml

version: 1
force:
  major: 1
  minor: 4
  patch: 12
  commit: 1c8e2eb628bc7c82f914b14b1163710be24ed510
wording:
  patch:
    - update
    - initial
  minor:
    - add
    - change
    - improve
  major:
    - breaking
    - the # For testing purposes

❯ semver-gen generate -c config.yml -r https://github.com/hipertracker/words_extractor
SEMVER 2.4.12

It should be 1.4.12

If I am not wrong, currently, the application can connect to only public repositories. It needs an option (or ENV variable) for connecting to private repositories.

The application should be able to start the calculations from the (optionally) defined commit instead form the first one (default). This should help to calculate the proper SEM numbers for the legacy code.

Eg.

force:
  major: 7
  minor: 4
  patch: 5
  commit: 1c8e2eb628bc7c82f914b14b1163710be24ed510

Hello,

I am trying to set up this tool for a project because of its simplicity. However, I could'nt figure out if there was a way to blacklist terms.

For example, I wanted to have something such as this:

  minor:
    - "feature:"

However, when I want to add features to the project, I name my branch feature/xxxx and then merge it into develop, which will trigger the version bump, in addition to the commits. Even worse, I am using gitlab merge requests feature and the merge commits often contain text from previous commits. This results in even the smallest changes bumping the version by a disproportionate amout every time.

This is making the tool close to unusable for me and I think this is a quite common workflow.

What do you think ? What is the expected workflow ?