fixes for: suffix.X in pre-tags bumps & refarctor some of the shell logic

[sbe-arg]

• too much variable reuse
• now u can bump vX.X.X-suff.X properly ie, v0.0.1-dev.0 bumps to v0.0.1-dev.1 for example for branch work rc release etc
• don't trust semver to tail, prefer head
• changed rexeg slightly to ignore latest non semver tags
• sorted pre-release mismatch when ur branch name contains master or main to behave correctly as pre-release anyway
• other small bits here and there

feel free to test from my fork: sbe-arg/github-tag-action@1.39.6

[alexeyatbluescape]

@sbe-arg
was testing it

Failed here: https://github.com/alexeyatbluescape/test-actions/runs/6525894935?check_suite_focus=true

Was trying to build beta version on 0-3-0 branch, but it tried to push 0.2.0-beta1 which already exists from the previous iteration.

My latest test branch: https://github.com/alexeyatbluescape/test-actions/tree/0-3-0

[sbe-arg]

@sbe-arg was testing it

Failed here: https://github.com/alexeyatbluescape/test-actions/runs/6525894935?check_suite_focus=true

Was trying to build beta version on 0-3-0 branch, but it tried to push 0.2.0-beta1 which already exists from the previous iteration.

My latest test branch: https://github.com/alexeyatbluescape/test-actions/tree/0-3-0

I reckon u are expecting this to bump #minor matching your branch from 0.2.0-suffix.x to 0.3.0-suffix.x u need to comment #minor on the commits otherwise it follows suffix sem bumps? is a bit turbulent area here where each use case is different and we need more use of comments to help the bumps I think.

But Ill try to replicate XD

[sbe-arg]

@alexeyatbluescape try 1.39.7 I think is just the semver output in new. f339bfb as is echoing the 0.3.0-beta from your build but not grabbing as $new

 * [new tag]         v0.2.0-beta.0 -> v0.2.0-beta.0
0.3.0-beta
Bumping beta pre-tag v0.2.0-beta.0. New pre-tag 0.2.0-beta.1

[alexeyatbluescape]

@sbe-arg looks better, but here is an interesting one:

Run: https://github.com/alexeyatbluescape/test-actions/actions/runs/2378342417

I was working on branch 0-4-0 and disabled prefix on 1st commit, instead of creating v0.4.0-beta.0 it created ``v0.3.0-beta.1` tag.

[sbe-arg]

I see is gonna be interesting to sort this
the order of events is:

get tags
query tags for x.x.x and x.x.x-suffix.x
if is a pre-release then x.x.x is ignored and we use x.x.x-suffix.x and bump it reason why u get the .0 to .1 bump

I understand the expectation is a bump to 0.4.0 in this particular case but for that to happen we need to compare between a pre-release semver x.x.x-suffix.x and main release semver x.x.x and not sure how well is that handled and how to protect this in other scenarios. will try a few things when I have some spare time.

happens around this block

github-tag-action/entrypoint.sh

Line 133 in f339bfb

if [[ "$pre_tag" =~ "$new" ]] && [[ "$pre_tag" =~ "$suffix" ]]

[morey-tech]

Our use case for CUSTOM_TAG is that we have a release branch for each minor version which requires that the 0 patch tag be created when the branch is created. For example, creating branch release-2.62 should create the 2.62.0 tag, then each commit to the branch after that increments the patch.

on: create
jobs:
  release:
    if: ${{ startsWith(github.ref, 'refs/heads/release-') }}
    steps:
      - name: Push Git Tag
        uses: anothrNick/github-tag-action@1.39.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CUSTOM_TAG: "<env>.0"

I know this isn't the ideal use of the action or the most correct implementation of semantic versioning but changing how the application is versioned is a different battle.

If this is functionality that is going to be removed, I'm happy switching to another method of pushing the base tag since it doesn't use any of the SemVer logic from the action. Though this should definitely result in a major version bump for the action.

[sbe-arg]

Our use case for CUSTOM_TAG is that we have a release branch for each minor version which requires that the 0 patch tag be created when the branch is created. For example, creating branch release-2.62 should create the 2.62.0 tag, then each commit to the branch after that increments the patch.

on: create
jobs:
  release:
    if: ${{ startsWith(github.ref, 'refs/heads/release-') }}
    steps:
      - name: Push Git Tag
        uses: anothrNick/github-tag-action@1.39.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CUSTOM_TAG: "<env>.0"

I know this isn't the ideal use of the action or the most correct implementation of semantic versioning but changing how the application is versioned is a different battle.

If this is functionality that is going to be removed, I'm happy switching to another method of pushing the base tag since it doesn't use any of the SemVer logic from the action. Though this should definitely result in a major version bump for the action.

this is actually a good used case Ill re add custom in this pr

[sammcj]

@anothrNick - Any update on getting this merged? We're noticing issues that this looks like it would fix.

[sbe-arg]

@morey-tech with the existing implementation without customtag and using reprelease-suffix

works like in this examples:

      - name: automatic-tag
        id: tag
        uses: sbe-arg/github-tag-action@1.39.7
        env:
          GITHUB_TOKEN: "${{ secrets.TOKEN }}"
          WITH_V: true
          PRERELEASE_SUFFIX: ${{ env.ENVIRONMENT }}
          DEFAULT_BUMP: patch

having custom to pass a custom tag but respecting the SEM ver calcullation breaks purpose.

semver -i prerelease ${pre_tag} --preid ${suffix}

[sbe-arg]

@sammcj the dilema is the customtag
with the new logic I break custom tag because it clashes functionality with prerelease suffix

Can everyone add comments around what custom_tag should do.
1- overwrite the semver and set stuff with and expecific fixed tag
2- another logic that I can document

[sbe-arg]

I have reinstated CUSTOM_TAG following the intend in readme making everything else irrelevant.
We can merge need some approval of the pr please @sammcj @morey-tech

[sammcj]

@sbe-arg I can't approve it as I'm not a repo maintainer, @anothrNick would you be able to approve please? (feel free to add me as a maintainer if you need help with PRs).

[sammcj]

While I can approve this, I can't merge it, @anothrNick are you able to approve / merge?

[sammcj]

Thanks @anothrNick

[anothrNick]

Released to 1.40.0. @sammcj I also added you as a collaborator.

Thank you.