[Tooling] Improve new_hotfix_release lane to work when there's no release tag

[iangmaia]

Related to AINFRA-1518

Description

This PR aims to add more robustness and require less manual intervention to the hotfix creation lane new_hotfix_release.

We have observed that sometimes it is possible that the release has been finalized but a release tag isn't present yet for some reason (likely due to the fact that the release hasn't been published yet), so release managers will get an error and require manual intervention.

This PR changes the code so that, if no release tag is present, we start the hotfix branch based on the corresponding release branch.

Testing instructions

There are basically 3 test scenarios that can be simulated:

1. There is a release tag that can be used to create the hotfix branch
2. There's no tag, but there's still a release branch that can be used to create the hotfix branch
3. There's no tag or branch (error)

To test it, you can create test branches / tags and run bundle exec fastlane new_hotfix_release skip_confirm:false version:"$VERSION" and then answer no after the prompt so that the lane execution stops and check the printed values.

For example:

1. Create and push release branch release/30.6 (which doesn't exist and has no corresponding tag for that version)
2. Run bundle exec fastlane new_hotfix_release skip_confirm:false version:30.6.1
3. It should use the release/30.6 branch instead of trying to use a tag. It should print:

New Hotfix:

• Current release version and build code: 26.4.1 (26.4.1.1).
• New release version and build code: 30.6.1 (30.6.1.0).

Branching from release/30.6

[mokagio]

Run from local release/99.9 that was not pushed to the remote

Tagged release/99.9 as 99.9 but did not push it:

Same but after adding remote: true as @AliSoftware suggested:

This shows another benefit of the suggestion: Ensuring the tag exists on the remote. I think this is beneficial because we can all make mistakes and it is possible (if contrived) that someone running the process on their machine might have a tag locally that has no match on the remote. A tag that exists only locally should be ignored, as the remote is the source of truth, especially when computing the release status.

After pushing release/99.9:

After pushing the tag as well:

Additional check for incorrect hotfix number, version:9.99.2:

On version that doesn't exist and different from current release branch:

Unrelated to the changes here, but we might want to add (possibly as a separate PR) a check to prevent passing a version that is not an hotfix to the lane.

E.g. bf new_hotfix_release skip_confirm:false version:26.4 gave me:

I suppose the process would have failed later on, but seems like a good check to add to fail early before risking pushing to the repo.

I think the

[iangmaia]

we might want to add (possibly as a separate PR) a check to prevent passing a version that is not an hotfix to the lane.

Great idea! I've added 5dcecde while we're here.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud