-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[Tooling] Improve new_hotfix_release lane to work when there's no release tag
#22355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
5e382c9 to
b4376a1
Compare
| # Parse the provided version into an AppVersion object | ||
| parsed_version = VERSION_FORMATTER.parse(new_version) | ||
| # Validate that this is a hotfix version (must have a patch component > 0) | ||
| UI.user_error!("Invalid hotfix version '#{new_version}'. Must include a patch number.") unless parsed_version.patch.to_i.positive? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick, and sort of out of scope because it would have required changing more of the existing code that this PR originally touched, but I noticed that other projects use hotfix_version as the name for this var, which to me sounds better in the context of this hotfix lane.
No big deal, it's just that the PR I looked before this used hotfix_version so this jumped to my attention, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think hotfix_version was an exception though, only DOApple (or maybe other one or two) used it, but admittedly I also like it 🙂 I'll update it in the PRs that are still open.
|
@AliSoftware I've implemented the last change we discussed about ensuring the hotfix branch doesn't exist on 56b313c . |
56b313c to
1f79171
Compare
|



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 it, if not 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:
To test it, you can create test branches / tags (⚠️ delete them later or, even better, use this technique of pointing your working copy’s ⚠️ ) and run
originremote to a local bare repo insteadbundle exec fastlane new_hotfix_release skip_confirm:false version_name:$VERSION build_code:$CODEand then answernoafter the prompt so that the lane execution stops and check the printed values.For example:
release/30.6(which doesn't exist and has no corresponding tag for that version)bundle exec fastlane new_hotfix_release skip_confirm:false version_name:30.6 build_code:9999release/30.6branch instead of trying to use a tag. It should print: