Use git_branch_name_using_HEAD instead of git_branch#463
Conversation
git_branch_name_using_HEAD instead of git_branch
spencertransier
left a comment
There was a problem hiding this comment.
I like this better because we can have a longer explanation and contain it in a single place. I think this also makes it more likely that we'll use it instead of git_branch when we need to use it somewhere new - although neither option can guarantee that.
I also like the 7669604 better. It feels cleaner and more self-explanatory, removing the need for the long comment each time the Fastlane helper is called directly.
(Not approving since auto-merge is enabled and I figured I'd let folks with better understanding weigh in here if needed)
Agreed. |
| require_relative '../../helper/git_helper' | ||
|
|
||
| UI.user_error!('This is not a release branch. Abort.') unless other_action.git_branch.start_with?('release/') | ||
| current_branch = Fastlane::Actions.git_branch_name_using_HEAD |
There was a problem hiding this comment.
Should current_git_branch be used here too?
There was a problem hiding this comment.
🤦 Yes it should be, thank you for catching that!
Addressed in f256ae5.
What does it do?
We have been using git_branch helper action to check if we are on a release branch during complete code freeze & finalize release steps. This has been working as expected in our local environments. However, the return value of this helper can be modified by environment variables such as
GIT_BRANCHorBUILDKITE_BRANCH. That means, if we switch the git branch during a CI step, it'll not return the value we are interested in.There is a
Fastlane::Actions.git_branch_name_using_HEADhelper method we can use, which is exactly what we expect.git_branchmethod actually wraps its implementation around this helper and adds the extra capability of modifying the return value with environment variables.We have 2 different approaches to address this issue.
Fastlane::Actions.git_branch_name_using_HEADeverywhere we need. The main issue with that is, we need to add a disclaimer about why we are using this method instead ofgit_branch.git_helper. I like this better because we can have a longer explanation and contain it in a single place. I think this also makes it more likely that we'll use it instead ofgit_branchwhen we need to use it somewhere new - although neither option can guarantee that.Checklist before requesting a review
bundle exec rubocopto test for code style violations and recommendationsspecs/*_spec.rb) if applicablebundle exec rspecto run the whole test suite and ensure all your tests passCHANGELOG.mdfile to describe your changes under the approprioate existing###subsection of the existing## Trunksection.