Open mrozanc opened 2 months ago
Why don't you just increment from last tag i.e. '2.3.0-rc.1' with with appropriate pattern?
Well, I'd like to use it on projects with people wanting to release often from the same base but not the same versions (because they don't have the time to do all the tests every time for changes they didn't plan but were integrated in the base project for other purposes).
Many versions of the project live at the same time in prod for different consumers.
Let's say we try to have all the latest features on the development branch. This first branch has always the last version number, that is not released. We "book" release versions from this branch, so we don't mix releases for different contents being prepared at the same time (I know this is not ideal, but we try to do like we can).
That's why I want to have the version number from the release branch name. It could be from a tag on the commit used to create the branch, but then it would be required to create a non-snapshot first version from here (which is OK, but would require at least a specific step in pipeline to ensure this is done), but also it would require to not have another tag on this commit, holding another version, which should be OK normally, but given how we are working, I'm sure there is a time this mess will happen. That's why I'd like to enforce only tags matching the branch name.
Another reason why I don't want to use things like empty commits to hold these tags is that I want to avoid commits by the pipeline, specifically because github actions and branch protection rules with commit checks are complicated to manage, and the bypass options for commit checks don't allow to push from the pipeline easily.
Here I wanted to be able to enforce the version mainly from branch name (and then by tags matching this version) with this extension only, and not by adapting the pipeline and actions around the project.
Maybe there would be some other way to ensure that, like by comparing the versions or something like that, but with static config it would be maybe less flexible.
I have this use case where I have branches containing a part of the version, but I need to resolve the rest of the version from the previous tags.
For example,
release/2.3
will set the base version to2.3.0
but on this branch, the release is still in preparation, so I need to check for specific tags that match the version from the branch (2.3.0-rc.1
and other increments starting with2.3
) in order to not mix any other tag versions with the release to go.I implemented a way to put placeholders in the
describeTagPattern
to find the right tags, like:The idea is that
{{
is normally not valid for regex if not escaped. If the key found is not part of the map, the placeholder is left untouched.