I added the first tag to a repo and tagged it with 1.0.0. However, the build version did not change. The GitTools/GitVersion tool does recognize the tag and increases the version to 1.0.0.

$ git tag
1.0.0

$ curl -Ls https://solugo.github.io/gitversion/run.sh | bash
0.0.241

# gittools
$ docker run --rm -v "$(pwd):/repo" gittools/gitversion:5.10.0-alpine.3.14-6.0 /repo
{
  "Major": 1,
  "Minor": 0,
  "Patch": 0,
...
  "MajorMinorPatch": "1.0.0",
  "SemVer": "1.0.0",
...
}

When using the tool on a shallow clone of a repository, the resulting version can to be 0.0.0. I faced the problem when using GitLab runners, which use shallow clones by default.

The solution for me was to ensure to have an unshallow clone by adding git fetch --unshallow to my CI. If you ask me, a hint to make sure to use an unshallow clone in case of a 0.0.0 return would be nice.

I pinned the version in a pipeline to v1.0.5, however, I accidently entered 1.0.5 at first. This simply results in a command not found error.

Instead I would expect the tool to tell me that the version/tag/release does not exist.

Add an example action.yml in this repo so that it can be re-used as a GitHub Action, cf.:

• https://docs.github.com/en/actions/creating-actions
• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses

Example github workflow:

jobs:
  version:
     steps:
        - uses solgo/actions/gitversion@<ref>
           ... output ...

GitHub recommends to place actions in separate repos, cf.:

• https://docs.github.com/en/actions/creating-actions/about-custom-actions#choosing-a-location-for-your-action