No tags are present for this repository

[nikwal-encare]

Get a warning about not tags are present in this repository and the version is not picked up:

The tag listing show:

> git describe --tags --abbrev=0
v0.4.0
> git tag
v0.2.0
v0.3.0
v0.4.0
> git for-each-ref --sort="-v:*refname" --format="%(refname:short)" --merged=HEAD "refs/tags/v*[0-9].*[0-9].*[0-9]"
v0.4.0
v0.3.0
v0.2.0

The version output is:
0.1.0-14
Expected version:
0.4.0-14

jobs:
  build:
    name: 🏗 Build
    runs-on: ubuntu-latest
    outputs:
      sversion: ${{ steps.semversion.outputs.version }}

    steps:
    - name: ⬇ Checkout 
      uses: actions/checkout@v3
      with:
        fetch-depth: 0

    - name: Tags
      run: git tag
       
    - name: 🔢 Semantic version 
      id: semversion
      uses: paulhatch/[email protected]
      with:
        tag_prefix: "v"
        major_pattern: "(MAJOR)"
        major_regexp_flags: ""
        minor_pattern: "(MINOR)"
        minor_regexp_flags: ""
        version_format: "${major}.${minor}.${patch}-${increment}"
        change_path: "."
        namespace: Example
        bump_each_commit: false
        bump_each_commit_patch_pattern: ""
        search_commit_body: false
        user_format_type: "csv"
        enable_prerelease_mode: false

[PaulHatch]

There is a new feature in v5.2.1 which I haven't had time yet to document properly, but if you set the debug input parameter to true the action will generate an additional output called debug_output which records each command run and the result in a JSON document. Aside from just being useful for troubleshooting generally, this can also be used to replay the action without the repo for debugging. It would be helpful if you could enable and share the diagnostic result here.

      - name: Version
        uses: paulhatch/[email protected]
        id: semversion
        with:
          debug: true
      - name: Print Diagnostic Output
        run: echo $DEBUG_OUTPUT
        env:
          DEBUG_OUTPUT: ${{ steps.semversion.outputs.debug_output }}

I may add a redaction option in the future to do this automatically, but in the meantime have a look at the output first and make sure you're comfortable posting it, feel free to change the author names/emails for example if they are not public.

[maksym-bondarchuk]

Same issue for me

- uses: actions/checkout@v3
  with:
    fetch-depth: 0
    fetch-tags: true

- name: Test version
  uses: paulhatch/[email protected]
  id: semversion
  with:
    tag_prefix: ""
    version_format: "${major}.${minor}.${patch}.${increment}"
    debug: true

- name: Print Diagnostic Output
  run: echo $DEBUG_OUTPUT
  env:
    DEBUG_OUTPUT: ${{ steps.semversion.outputs.debug_output }}

paulhatch/[email protected] outputs

Warning: No tags are present for this repository. If this is unexpected, check to ensure that tags have been pulled from the remote.
Version is 0.0.1.2484

but the expected version is 4.4.29.*

Here is my debug output

{
	"commands": [
		{
			"command": "git",
			"args": [
				"rev-list",
				"-n1",
				"--all"
			],
			"output": "4faeafc5fd428322a4251ebac06157df486059c6\n",
			"stderr": "",
			"error": null
		},
		{
			"command": "git",
			"args": [
				"rev-parse",
				"HEAD"
			],
			"output": "4faeafc5fd428322a4251ebac06157df486059c6\n",
			"stderr": "",
			"error": null
		},
		{
			"command": "git tag --points-at 4faeafc5fd428322a4251ebac06157df486059c6 *[0-9].*[0-9].*[0-9]",
			"args": [],
			"output": "",
			"stderr": "",
			"error": null
		},
		{
			"command": "git for-each-ref --sort=-v:*refname --format=%(refname:short) --merged=4faeafc5fd428322a4251ebac06157df486059c6 refs/tags/*[0-9].*[0-9].*[0-9]",
			"args": [],
			"output": "4.4.28.0\n4.4.27.4\n4.4.26.23\n4.4.25.13\n4.4.24.36\n",
			"stderr": "",
			"error": null
		},
		{
			"command": "git",
			"args": [
				"remote"
			],
			"output": "origin\n",
			"stderr": "",
			"error": null
		},
		{
			"command": "git log --pretty=\"@@@START_RECORD%n@@@hash%n%H%n@@@subject%n%s%n@@@body%n%b%n@@@author%n%an%n@@@authorEmail%n%ae%n@@@authorDate%n%aI%n@@@committer%n%cn%n@@@committerEmail%n%ce%n@@@committerDate%n%cI%n@@@tags%n%d\" --author-date-order 4faeafc5fd428322a4251ebac06157df486059c6",
			"args": [],
			"output": "<REDACTED, TOO LONG>",
			"stderr": "",
			"error": null
		}
	],
	"empty": false
}

I tested 5.2.0, 5.2.0, 5.1.0, 5.0.3, 5.0.2, 5.0.1, and 5.0.0 - same warning for all these versions. The last working version for me is 4.0.3 (I don't know if there are any versions between 4.0.3 and 5.0.0

[PaulHatch]

tl;dr You need to use a tag format that matches the configuration you have, in your case it looks like that's {major}.{minor}.{patch}. You can add other tags if you want, but these will be ignored.

This command is being used to identify the last version tag:

git for-each-ref --sort=-v:*refname --format=%(refname:short) --merged=4faeafc5fd428322a4251ebac06157df486059c6 refs/tags/*[0-9].*[0-9].*[0-9]

This list is then filtered to find the first suitable tag that matches the expected pattern using tagFormatter.IsValid, which by default uses this implementation:

public IsValid(tag: string): boolean {
    const regexEscape = (literal: string) => literal.replace(/\W/g, '\\$&');
    const tagPrefix = regexEscape(this.tagPrefix);
    const namespaceSeperator = regexEscape(this.namespaceSeperator);
    const namespace = regexEscape(this.namespace);

    if (!!this.namespace) {
      return new RegExp(`^${tagPrefix}[0-9]+\.[0-9]+\.[0-9]+${namespaceSeperator}${namespace}$`).test(tag);
    }

    return new RegExp(`^${tagPrefix}[0-9]+\.[0-9]+\.[0-9]+$`).test(tag);
  }

So as you can see, if you don't have a namespace set it is checking for the version prefix (almost always either v or and empty string) followed by three numbers separated by dots (.), the format of the version tag does not necessarily align with the semantic version. There is not a standard spec for tags, this merely follows the standard convention.

Now the result we see for this command in the diagnostic output above is:

4.4.28.0
4.4.27.4
4.4.26.23
4.4.25.13
4.4.24.36

All of these are using 4 number versions, so all will be rejected, leaving you with no valid tags present. This action assigns the "increment" value itself which can be optionally used by you however you like in the build, but this value is not part of the semantic version spec and is not supported as an input.

The reason this may have worked previously is because in previous versions the action relied solely on the git command to return the version. Ideally we would not need to run the command with the filter and then immediately filter the result as we are, but unfortunately the glob pattern supported by Git is not as robust as regex and was including tags that should not have been included, you're seeing the point where this was fixed.

I am updating the warning message to distinguish between these two cases by checking the total number of tags found and showing a warning about the format rather than saying no tags found.

[maksym-bondarchuk]

Thanks for the explanation, switching to {major}.{minor}.{patch} format solved the issue for me