semantic-version icon indicating copy to clipboard operation
semantic-version copied to clipboard

`version_from_branch` usage

Open kirillmorozov opened this issue 1 year ago • 3 comments

Hi,

First of all I'd like to thank you for a very helpful action that I use everywhere I can.

Version 5.3.0 introduced branch-based versioning mode which I use in a repo that uses release branches.

We create a branch from our default branch named release/MAJOR.MINOR where MAJOR and MINOR are corresponding parts of version that we expect to release from this branch and then start a release workflow that resolves version using your action and then creates a GitHub release.

Today I started this release workflow from release/11.2 branch and was very surprised to discover that the resolved version was 12.0.0 while I've expected it to be 11.2.0.

This is the output of Checkout action that shows the branch name:

/usr/bin/git checkout --progress --force -B release/11.2 refs/remotes/origin/release/11.2

And here are the inputs I use for your action:

uses: paulhatch/[email protected]
with:
  debug: true
  tag_prefix: ""
  version_from_branch: true
  major_pattern: '/^\w*(?:\(\w*\))?!:/'
  minor_pattern: '/^feat(?:\(\w*\))?!?:/'
  version_format: ${major}.${minor}.${patch}
  bump_each_commit: false
  search_commit_body: false
  namespace: ""

And here's a warning I got for this run but I'm not sure what it means:

Warning: None of the 1 tags(s) found were valid version tags for the present configuration. If this is unexpected, check to ensure that the configuration is correct and matches the tag format you are using.

Could you please explain how to correctly configure this action to use branch-based versioning?

I'm also interested in a way to use this action in a flow that has a default branch and release branches from it. So far I came up with a workaround to create MAJOR.MINOR.0 tags on a commit I create release/MAJOR.MINOR branch from so that this action can resolve future versions based on this tag but I'm not sure this is a best option.

kirillmorozov avatar Feb 08 '24 16:02 kirillmorozov

With version_from_branch set to true, if you are on branch release/11.2 the version should always be 11.2.*.

There is a method called ResolveBranchNameAsync which should call git rev-parse --abbrev-ref HEAD to obtain the branch name. Could you enable debug mode and ensure that this command is returning release/11.2 as expected?

Regarding the warning, that is indicating that 1 tag was returned, but it was not considered a valid version tag and was ignored, for example you have set the tag_prefix to an empty string, but you might have a tag like v1.0.0 which would be ignored due to the v prefix.

PaulHatch avatar Feb 09 '24 01:02 PaulHatch

I will enable debug mode for all future workflow runs but I'm not sure I could reproduce the exact same issue cause I've already altered tags in the repo manually.

I'll keep running our workflows with the debug mode on and if it happens again, I'll update the issue with all info that I'll gather.

kirillmorozov avatar Feb 09 '24 09:02 kirillmorozov

using paulhatch/[email protected] I was having the same warning: Warning: None of the 1 tags(s) found were valid version tags for the present configuration. If this is unexpected, check to ensure that the configuration is correct and matches the tag format you are using

updating the checkout action to the latest seem to have worked

name: Checkout code uses: actions/[email protected]

jhernandez-kr avatar Sep 05 '24 20:09 jhernandez-kr