Specify base version number

[nturnerlivanova]

Is it possible to specify the base version number. For instance, if the pre-existing tagged version before using this tool was 2.0.1. Can I specify that in the yml to use that as the base?

[PaulHatch]

There is not currently a way to specify this in the config, though you can just tag any previous commit v2.0.1 to set the last version and the action will pick it up.

An "initial version" does seem like a good future feature, I'll keep this open as a future enhancement. Still in this scenario I think you'd better off assigning the previous version tags if possible. After your first release a value included in the build YAML like that isn't going to have much meaning.

[nturnerlivanova]

@PaulHatch It doesn't seem to be finding my existing tags. Is this based on branch for searching? Our branches are no the norm. We have a prerelease branch that we make tags for.

It doesn't seem to be finding my 2.0.1 tag. Is there something I should be doing to help it locate our tags in the repo?

[PaulHatch]

If your tag is just 2.0.1 you need to specify that the tag_prefix is and empty string, as the default is "v" and it will be looking for a tag named like v2.0.1.

- uses: paulhatch/[email protected]
  with:
    tag_prefix: ""
    ...

Aside from that it should be able to find the tag so long as the commit it is on is merged. The command it would use with this configuration would look like this git tag --points-at ${current_commit} "*[0-9].*[0-9].*[0-9]", you can see it here. There is also a branch version resolver behavior available, though having used both on different production projects I recommend sticking with tags unless you need to maintain multiple versions of the product with ongoing releases.

[nturnerlivanova]

@PaulHatch does this only work on the beta? maybe thats my issue it is v2.0.1 and I have the prefix as v . I'm using v4.0.2 of your tool

[PaulHatch]

No, this has been the behavior from the beginning--one other thing to check for is that you are pulling enough history to include the tag. The default behavior of actions/checkout does not include the history starting in v2.

[nturnerlivanova]

@PaulHatch thanks for your quick answers I'll look and see what i'm doing wrong

[nturnerlivanova]

@PaulHatch It's still not picking up my "v2.0.1" can you look at my code and maybe i'm doing something wrong

 - uses: paulhatch/[email protected]
    id: version
    with:
      # The prefix to use to identify tags
      tag_prefix: "v"
      # A string which, if present in a git commit, indicates that a change represents a
      # major (breaking) change, supports regular expressions wrapped with '/'
      major_pattern: "(MAJOR)"
      # Same as above except indicating a minor change, supports regular expressions wrapped with '/'
      minor_pattern: "(MINOR)"
      # A string to determine the format of the version output
      format: "v${major}.${minor}.${patch}-prerelease${increment}"
      bump_each_commit: false

[nturnerlivanova]

I see this warning: No tags are present for this repository. If this is unexpected, check to ensure that tags have been pulled from the remote.

tried with fetch depth of 0 and 2

I have 6 tags in this private repo

I ran a step before your tool "git tag" and it finds all tags, so i'm not sure why the tools says not found

[nturnerlivanova]

@PaulHatch Here''s what I found out. HEAD is not showing the tags since we specify to a specific branch

`Run paulhatch/[email protected]
with:
branch: origin/verification
tag_prefix: v
major_pattern: (MAJOR)
minor_pattern: (MINOR)
version_format: v${major}.${minor}.${patch}-prerelease${increment}
bump_each_commit: false
use_branches: false
search_commit_body: false
user_format_type: csv
env:

Warning: No tags are present for this repository. If this is unexpected, check to ensure that tags have been pulled from the remote.
No changes detected for this commit
Version is v2.0.1-prerelease0`

I think that's correct? I assume then once I create a PR with the word MINOR the version will be incremented.

[PaulHatch]

Currently only the commit message is used to determine the version type. There is an open enhancement ticket for this which is currently planned for v5.1.0.

The branch name should generally be left alone, assuming you are interested in getting a version for the current HEAD position, which is pretty much always going to be the case. That warning message indicates that when attempting to determine the previous release, no tag was found. To fix this ensure that:

• A previous tag exists (you will get this warning until the first tag is added)
• The commit of the tag is an ancestor of the current commit
• The commits and tags have been pulled (for actions/checkout you need to specify a fetch-depth that ensures the last versioned commit is included)
• The previous tag is in the correct format, in particular make sure the tag prefix is correct
• Tags have been pulled (this is the default behavior of the checkout action, so usually this is not the issue)