Create Installable Builds with Buildkite#17581
Conversation
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
87c7282 to
9153b24
Compare
| bundle exec fastlane run configure_apply | ||
|
|
||
| echo "--- :hammer_and_wrench: Building" | ||
| bundle exec fastlane build_and_upload_jetpack_installable_build build_number:$BUILDKITE_PULL_REQUEST |
There was a problem hiding this comment.
Given the similarities between the 2 scripts (WP vs JP) I wonder if it wouldn't be better to provide the target as argument?
- Either by making a common lane
build_and_upload_installable_build app:{wordpress|jetpack} build_number:<value>(which could then internally in theFastfileswitch on the parameter and call the appropriate original lane?) – and then pass down thatapp:argument from the pipeline to the.shto the fastlane call - Or by keeping individual lanes and make the switch at the
.shlevel to call the appropriate lane (which would make a smaller change and allow to detect typos earlier)
This could even be something as simple as:
| bundle exec fastlane build_and_upload_jetpack_installable_build build_number:$BUILDKITE_PULL_REQUEST | |
| APP="$1" | |
| bundle exec fastlane "build_and_upload_${APP}_installable_build" build_number:$BUILDKITE_PULL_REQUEST |
That would avoid the duplication (and double-maintenance) for the 2 otherwise similar cases 🙂
There was a problem hiding this comment.
The repetition here exists for all of the other commands too, which was why I figured this was ok. It'd be possible to extract it all our into a shared install-dependencies.sh file, but in the past I've found we've run into a lot of weirdness when we try to over-DRY things 😅
| gem install bundler | ||
|
|
||
| echo "--- :rubygems: Setting up Gems" | ||
| restore_cache "$(hash_file .ruby-version)-$(hash_file Gemfile.lock)" |
mokagio
left a comment
There was a problem hiding this comment.
Looking good. Left just one question about a possible early return.
.buildkite/pipeline.yml
Outdated
| - label: ":pipeline: Build" | ||
| - label: ":pipeline: Build for Testing" |
| Jetpack Nightly: | ||
| triggers: | ||
| - schedule: | ||
| cron: "0 0 * * *" | ||
| filters: | ||
| branches: | ||
| only: | ||
| - develop | ||
| jobs: | ||
| - Jetpack Installable Build |
There was a problem hiding this comment.
I checked the Buildkite schedules tab and there is no equivalent for this.
Has it been deemed unnecessary?
There was a problem hiding this comment.
I'll let Jeremy reply but my guess is, since we'll now create Installable Builds for all PRs without waiting for confirmation (i.e. we won't have the "Hold" job anymore), this indeed kinda makes those Nightly Builds irrelevant anymore?
There was a problem hiding this comment.
Yep, this is the case – we can also trivially re-add it with a separate pipeline file, but I'd like to see if it's actually needed :)
Gemfile.lock
Outdated
| revision: 83e4d5f036f1871ce6f8e9411550d4040cebddca | ||
| branch: add/github-comment-action |
There was a problem hiding this comment.
Asking because the PR is "Ready for review", not the "Draft": do you plan on shipping a new release toolkit build before merging this?
IMHO it would be appropriate, but I'm okay if it doesn't happen.
There was a problem hiding this comment.
Just chiming in to say that since I likely won't get back to edit the release-toolkit (to port more actions to it as part of my L10n project) that soon, as I'm still working on the client apps's widgets and extensions, I'm ok with us doing a minor version of the release-toolkit for this if deemed appropriate indeed. I'll soon need to work on a couple of new actions (for the Siri Intents and all) but that can totally go in a separate release-toolkit minor version after we do a new release for this.
That is, as long as @mokagio you confirm that you fixing your local env on wordpress-mobile/release-toolkit#314 (comment) and wordpress-mobile/release-toolkit#315 (comment) fixed those issues you had and that those are not blockers to making a new version which would include localization changes too.
PS: I'll make a quick PR to isolate my change that fixes #314 so it can be merged easier (rather than waiting for my PR on next widget to land) – EDIT: done in #17627
There was a problem hiding this comment.
I'm following @AliSoftware's lead on this, so I'm fine to continue to target develop (I'll update this reference) as long as he needs to, or move to a tag if one is created.
There was a problem hiding this comment.
I followed up on the dirname issue confirming it was due to messed up state on my end. Still unclear about the --tags one, but #17627 will prevent it from happening during a code freeze again (whatever the tags-related cause is), so we're good 👍
| # Install SentryCLI prior to trying to upload dSYMs | ||
| sh('curl -sL https://sentry.io/get-cli/ | bash') | ||
|
|
There was a problem hiding this comment.
The fact that CI passes is proof enough that this is unnecessary now, but for reference, this is unnecessary because our CI agents are provisioned with it already.
There was a problem hiding this comment.
Is this impacting our confidence in being able to run a release build locally in an emergency, if we needed to?
There was a problem hiding this comment.
Good question – I'd be fine to do something like an UI.user_error('Sentry not installed') unless sh('command -v sentry-cli') in a before hook to preserve running locally in an uninitialized environment, but IMHO having a curl $ANYTHING | bash is generally a bad idea (though if you blame this file, I think I'm the one who put this here... 😅 )
There was a problem hiding this comment.
I like the idea of erroring out if a pre-required external tool is not available, with a suggestion on how to install it, but without doing it for the user.
If we attempted to install it, we'd take on board the responsibility of keeping the install code working and up to date.
| dsym_path: lane_context[SharedValues::DSYM_OUTPUT_PATH] | ||
| ) | ||
|
|
||
| return if ENV['BUILDKITE_PULL_REQUEST'].nil? |
There was a problem hiding this comment.
Have you considered moving this check to the start of the lane? Is there a use case in which we would run all the above not on a pull request?
There was a problem hiding this comment.
Is there a use case in which we would run all the above not on a pull request
I don't know of one, but I also can't entirely rule it out (for instance, @startuptester had requested the ability to create an installable build of develop on-demand from a webhook, which I think could call this action and "just work")
Co-authored-by: Olivier Halligon <olivier.halligon@automattic.com>
Yep addressed in 19e1106 |
FWIW I was about to submit a bug report to Buildkite, but then noticed that other people beat me to it, so logging this here for reference:
I wonder if we could push this back into their radar by pinging them on our Slack Connection with them? 🤔 [EDIT] Note that the Forum answer hints at the fact that they were working on this back in 2020. I took a look at the docs again and I saw that there's a |
|
@AliSoftware I've used the |
That looks perfect 👍 Note I see that the 22 checks on this PR still include both the old and new names, but I'm assuming it's because those checks ran with the old name before you made the change and that's why they still appear here, and wouldn't in subsequent PRs once this is merged, right? (And sorry, I didn't intent to derail the original intent of this PR that much with that aside about CI check names 😅 ) |
This is my assumption as well 🙂 |
AliSoftware
left a comment
There was a problem hiding this comment.
- Inconsistencies in WP vs JP, both in build number used and logic to derive it.
- Misssing check for sentry
- Obsolete
require
fastlane/Jetpack-Fastfile
Outdated
| desc "Builds and uploads a Jetpack installable build" | ||
| lane :build_and_upload_jetpack_installable_build do | options | | ||
| jetpack_alpha_code_signing | ||
| require 'git' |
There was a problem hiding this comment.
This os obsolete now that we rely on the last_git_commit action
|
|
||
| # Install SentryCLI prior to trying to upload dSYMs | ||
| sh("curl -sL https://sentry.io/get-cli/ | bash") unless sh("which sentry-cli") | ||
|
|
There was a problem hiding this comment.
No call to ensure_sentry_installed here to replace this deleted code?
fastlane/Jetpack-Fastfile
Outdated
| short_hash = last_git_commit[:abbreviated_commit_hash] | ||
|
|
||
| build_number = [ | ||
| short_hash, | ||
| '-', | ||
| Time.new.strftime("%Y%m%d-%H%M") | ||
| ].join |
There was a problem hiding this comment.
Any reason why the build_number for Jetpack is forced to be this <sha1-Ymd-HM> (nice) but Wordpress does not seem to follow that same logic in the main Fastfile?
Why not make WordPress follow the same version format?
| bundle exec fastlane run configure_apply | ||
|
|
||
| echo "--- :hammer_and_wrench: Building" | ||
| bundle exec fastlane build_and_upload_jetpack_installable_build build_number:$BUILDKITE_PULL_REQUEST |
There was a problem hiding this comment.
bundle exec fastlane build_and_upload_jetpack_installable_build build_number:$BUILDKITE_PULL_REQUEST
According to the Jetpack-Fastfile the build_number parameter is totally unused in the case of Jetpack, as instead the sha1 and datetime are used as build number.
We should definitively uniformize this so that both WP and JP use the same build-number format, especially when they're both related to the same build and commit, so we won't compare apple to oranges.
I like the idea of having the BUILDKITE_PULL_REQUEST as part of the build number if it's present, though including the sha1 even if it comes from a PR seems relevant to differentiate Installable Builds from same PR but generated before/after additional commits being pushed to the PR. I don't really see a strong point in having the date and time in the build number tho.
I'd suggest to use a similar format to what is used with Android, namely prNNN-sha1 for Installable Builds made from PRs, and trunk-sha1 for the ones one might build from a branch (e.g. if an EW manually triggers a build on the current trunk branch to test it, or if we do nightly builds, etc?).
Something like this probably (not tested):
| bundle exec fastlane build_and_upload_jetpack_installable_build build_number:$BUILDKITE_PULL_REQUEST | |
| if [[ "$BUILDKITE_PULL_REQUEST" == "false" ]]; then | |
| BUILD_NUMBER="${BUILDKITE_BRANCH}-${BUILDKITE_COMMIT:0:7}" | |
| else | |
| BUILD_NUMBER="pr${BUILDKITE_PULL_REQUEST}-${BUILDKITE_COMMIT:0:7}" | |
| fi | |
| bundle exec fastlane build_and_upload_jetpack_installable_build build_number:"$BUILD_NUMBER" |
Then you'd need to ensure that the logic in the Jetpack-Fastfile for JP is the same as the one in the Fastfile for WP.
There was a problem hiding this comment.
Addressed in de0c32a – I like the format, but I moved the logic into Ruby – this makes it a bit easier to maintain IMHO, and also drops the requirement for build numbers to be specified on the command line – the lane has enough information in any case to decide what it should be called.
If, in the future, we need the ability to override it, I'd be fine to add the option back in.
|
@jkmassel I'm going to bump this to the next release because we'll be code freezing 19.0 today and it seems like this needs a bit more touches. |
|
I'm going to bump this to the next release because we'll be code freezing 19.1 today and it seems like this needs a bit more touches. |
…ds-to-prs # Conflicts: # .circleci/config.yml # Gemfile.lock
Pull Request is not mergeable
Pull Request is not mergeable
AliSoftware
left a comment
There was a problem hiding this comment.
Looks all great now 👍 ![]()
PS: Just saw that my last review ended up being individual comments instead of a proper PR review submission, sorry 😅 (did it from my phone which is probably what misled me 😅 )
| branch = ENV['BUILDKITE_BRANCH'] | ||
| pr_num = ENV['BUILDKITE_PULL_REQUEST'] | ||
|
|
||
| return pr_num == 'false' ? "#{branch}-#{commit}" : "pr#{pr_num}-#{commit}" |
There was a problem hiding this comment.
Way more readable than the previous way 👍 👏
|
|
||
| comment_on_pr( | ||
| project: 'wordpress-mobile/wordpress-ios', | ||
| pr_number: Integer(ENV['BUILDKITE_PULL_REQUEST']), |
There was a problem hiding this comment.
nit: never seen the use of Integer(string) in Ruby before, TIL, as I believe the idiomatic way to do that usually is to use string.to_i instead 🙃
|
🎉 |

Moves installable builds from CircleCI to Buildkite.
Uses the release toolkit to post the installable build instructions instead of writing out a file for Peril – apart from that, it works the same way.
To test:
paranoiacredit: try installing the App Center builds to ensure they work.Regression Notes
Potential unintended areas of impact
Could theoretically break installable builds.
What I did to test those areas of impact (or what existing automated tests I relied on)
Checked that they were actually posted to App Center.
What automated tests I added (or what prevented me from doing so)
n/a
PR submission checklist:
RELEASE-NOTES.txtif necessary.