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
Fastlane setup improvements before release in CI automation #22191
Conversation
This way it can be shared with the lanes for CI in the future and also easily hacked during testing.
# Other defines used across multiple lanes | ||
REPOSITORY_NAME = 'WordPress-iOS' | ||
|
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.
Was unused.
def compute_release_branch_name(options:, version: release_version_current) | ||
branch_option = :branch | ||
branch_name = options[branch_option] | ||
|
||
if branch_name.nil? | ||
branch_name = release_branch_name(version:) | ||
UI.message("No branch given via option '#{branch_option}'. Defaulting to #{branch_name}.") | ||
end | ||
|
||
branch_name | ||
end |
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 moved this in Fastfile
because it will be shared between lanes across files.
I don't remember why we need this computation logic over using the simpler interpolation from release_branch_name(version:)
.
I decided to roll with it instead of investigating to make faster progress with the release automation.
def ensure_git_branch_is_release_branch | ||
# Verify that the current branch is a release branch. Notice that `ensure_git_branch` expects a RegEx parameter | ||
ensure_git_branch(branch: '^release/') | ||
end |
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 like this because I think the method name clearly explains what the method does, and we have moved the awkwardness with the explanation comment and RegExp input in a single, out of sight, place.
📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
|
Generated by 🚫 Danger |
📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
|
Adding @spencertransier as a reviewer since you're doing something similar in WooCommerce iOS, woocommerce/woocommerce-ios#11367 (which I haven't had a chance to comment upon yet) |
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.
Looks great! I left a couple minor comments, but it's good to go as is
One of these comments is somewhat important (related to FL_GIT_BRANCH_DONT_USE_ENV_VARS
) but it won't matter until we start doing releases in CI.
|
||
def ensure_git_branch_is_release_branch | ||
# Verify that the current branch is a release branch. Notice that `ensure_git_branch` expects a RegEx parameter | ||
ensure_git_branch(branch: '^release/') |
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.
ensure_git_branch
depends on environment variables, which means when we run the release automation in CI, the branch name it'll check is the one passed from Buildkite instead of the actual branch we are on. To avoid this, we need to add FL_GIT_BRANCH_DONT_USE_ENV_VARS
env var as we do in WPAndroid.
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.
Noted. I didn't run into this issue during my tests, #22194, but maybe it was due to some additional test setup...
However, this might explain something that surprised me and that I filed for investigation. In the screenshot below from this build the git_branch
output is the branch the lane started on, not the new one.
Addressed in d9691c6
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.
Yeap, that's the exact issue that environment variable addresses. If you'd like to learn more about it, here is the PR that we submitted to fastlane
.
|
||
# Create the release branch | ||
release_branch_name = compute_release_branch_name(options:, version: release_version_next) |
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.
It looks like we've already calculated the release_branch_name
in line 25. (at the time of this comment)
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.
Good catch! Thanks.
Address in fb1ddac
• New internal release version and build code: #{release_version_next} (#{build_code_code_freeze_internal}) | ||
MESSAGE | ||
|
||
UI.important(message) |
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.
How do you feel about always printing the message
outside of the skip_user_confirmation
check to make the information available in CI logs?
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.
My rationale for only printing in interactive mode was that there's no point in showing that message if the user cannot act on it.
But.. your point of making information available in the CI logs is quite valid. Who knows, there might be a bug at some point in how the codes are evaluated, like it happened in #22087, at which point having logs might be a huge help in diagnosing.
Addressed in 2f8c867
• New internal build code: #{build_code_next_internal} | ||
MESSAGE | ||
|
||
UI.important(message) |
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.
Similar to a previous comment, how do you feel about always printing the message
outside of the skip_user_confirmation
check to make the information available in CI logs?
push_to_git_remote(tags: false) | ||
trigger_beta_build | ||
else | ||
unless skip_user_confirmation || UI.confirm('Ready to push changes to remote and trigger the beta build?') | ||
UI.message('Aborting code freeze completion. See you later.') |
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 know this is not in the changeset, but this message feels a bit off to me. When we run this lane locally, the code freeze is completed at this point - we just didn't push it to remote yet.
It does make sense in CI, because if the change is not pushed, then it's discarded. However, that's not the case for local. 🤷
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 see your point. I reworded it with something that is hopefully clearer in 919d62c. Open to suggestions in the upcoming PR.
Thank you for the review @oguzkocer 🙇♂️ I'll merge this to move the project forward, but all your feedback is valuable and I'll address it in a followup PR. |
See conversation at #22191 (comment)
This does some tidy up before we add additional lanes and CI pipelines for release automation.
The main changes are:
skip_confirm
to drive all the interactive settings of various commands. This way, CI can passskip_confirm:true
and run everything in non-interactive mode.Regression Notes
Potential unintended areas of impact – Some of the release automation might have broken. As the release manager, I'll deal with if I run into it.
What I did to test those areas of impact (or what existing automated tests I relied on) – Run it on test branches.
What automated tests I added (or what prevented me from doing so) – N.A.
PR submission checklist:
RELEASE-NOTES.txt
if necessary. N.A.UI changes testing checklist: Not a UI PR.