Skip to content
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

Merged
merged 12 commits into from Dec 12, 2023

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Dec 8, 2023

This does some tidy up before we add additional lanes and CI pipelines for release automation.

The main changes are:

  • Centralize the release branch name definition and check, which makes it handy to change the branch name for testing
  • Use one parameter only, skip_confirm to drive all the interactive settings of various commands. This way, CI can pass skip_confirm:true and run everything in non-interactive mode.

Regression Notes

  1. 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.

  2. What I did to test those areas of impact (or what existing automated tests I relied on) – Run it on test branches.

  3. What automated tests I added (or what prevented me from doing so) – N.A.

PR submission checklist:

  • I have completed the Regression Notes.
  • I have considered adding unit tests for my changes. N.A.
  • I have considered adding accessibility improvements for my changes. N.A.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary. N.A.

UI changes testing checklist: Not a UI PR.

Comment on lines -29 to -31
# Other defines used across multiple lanes
REPOSITORY_NAME = 'WordPress-iOS'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was unused.

Comment on lines +282 to +292
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
Copy link
Contributor Author

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.

fastlane/lanes/release.rb Outdated Show resolved Hide resolved
@mokagio mokagio added the Tooling Build, Release, and Validation Tools label Dec 8, 2023
Comment on lines +298 to +301
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
Copy link
Contributor Author

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.

@wpmobilebot
Copy link
Contributor

wpmobilebot commented Dec 8, 2023

Jetpack Alpha📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
App NameJetpack Alpha Jetpack Alpha
ConfigurationRelease-Alpha
Build Numberpr22191-3cd2521
Version23.8
Bundle IDcom.jetpack.alpha
Commit3cd2521
App Center Buildjetpack-installable-builds #7100
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@mokagio mokagio marked this pull request as ready for review December 8, 2023 05:17
@wpmobilebot
Copy link
Contributor

1 Warning
⚠️ PR is not assigned to a milestone.

Generated by 🚫 Danger

@wpmobilebot
Copy link
Contributor

WordPress Alpha📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
App NameWordPress Alpha WordPress Alpha
ConfigurationRelease-Alpha
Build Numberpr22191-3cd2521
Version23.8
Bundle IDorg.wordpress.alpha
Commit3cd2521
App Center BuildWPiOS - One-Offs #8080
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@mokagio mokagio added this to the 24.0 milestone Dec 11, 2023
@mokagio
Copy link
Contributor Author

mokagio commented Dec 12, 2023

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)

Copy link
Contributor

@oguzkocer oguzkocer left a 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 :shipit:

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/')
Copy link
Contributor

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.

Copy link
Contributor Author

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.

image

Addressed in d9691c6

Copy link
Contributor

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)
Copy link
Contributor

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)

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Contributor Author

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)
Copy link
Contributor

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.')
Copy link
Contributor

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. 🤷

Copy link
Contributor Author

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.

@mokagio
Copy link
Contributor Author

mokagio commented Dec 12, 2023

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.

@mokagio mokagio merged commit d6ec2c9 into trunk Dec 12, 2023
23 checks passed
@mokagio mokagio deleted the mokagio/fastfile-improvements branch December 12, 2023 23:54
mokagio added a commit that referenced this pull request Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Tooling Build, Release, and Validation Tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants