Description
Bug description
Semantic versioning patch field does not behave as expected when the most recent tag has major, minor, and tag in it.
How to reproduce
- Create workflow with
uses: game-ci/unity-builder@v4
to build a project - Add a tag
v0.1
a couple CLs back (or submit a couple CLs after) - Build with GitHub Actions
- See that the built project
outputs.buildVersion
is something like0.1.14
as expected - Delete the tag and instead add a tag
v0.1.0
a couple CLs back - Build with GitHub Actions
- See that the built project
outputs.buildVersion
is0.1.0
which is NOT as expected
Expected behavior
Based on the docs for Semantic
versioning here I would expect the major
and minor
versions to be dictated by the most recent tag, but for the patch
to always be the number of CLs since the tag.
Additional details
I would like to have GitHub Actions automatically create a tag for each release with the version. So for example, if commit 8db7eea
is built to create 0.1.14
, I would like to have it create the tag v0.1.14
on that commit. This behavior prevents me from doing that.
I believe that the cause is in the src/model/versioning.ts
file. With 3 field in the version, getVersionDescription
would something like v0.12.15-24-gd2198ab
(If the tag was v.0.12.15
). parseSemanticVersion
would then match on the first descriptionRegexes
to generate [match=..., tag='0.12.15', commits='24', hash='d2198ab']
. Then inside generateSemanticVersion
we would combine tag and commits with const [major, minor, patch] =
${tag}.${commits}.split('.');
to create '0.12.15.24'
, but we only look at the first 3 so it would resolve to '0.12.15
'.