Use Xcode Cloud to build SDK releases #4200
Conversation
| - script@1: | ||
| inputs: | ||
| - content: bundle exec ./ci_scripts/export_builds.rb | ||
| is_always_run: true | ||
| title: Export builds |
There was a problem hiding this comment.
I'm concerned that adding this could significantly increase the time it takes to run checks on each PR. It makes sense to run this nightly, but maybe we should consider configuring bitrise to pull deploy-dry-run out of the main pipeline and only into nightly and release pipelines.
Okay to leave it for now, but if we find that checks are taking too long, we may want to do a light refactor of our bitrise config.
There was a problem hiding this comment.
Huh, I thought deploy-dry-run was nightly! Looks like we're also running it on main branches too, which is incorrect. I'll fix it
| @@ -48,7 +48,6 @@ stages: | |||
| - ui-tests-3: {} | |||
| - ui-tests-4: {} | |||
| - integration-all: {} | |||
| - deploy-dry-run: {} | |||
There was a problem hiding this comment.
This also removes it from releases-trigger-pipeline. Are we okay with that?
I'm guessing this is okay given that we would be manually executing the deploy for releases, but it would mean that we wouldn't catch any breakages until we attempt to run the deploy scripts as opposed to catching them earlier in CI.
There was a problem hiding this comment.
I think it was never running in releases-trigger-pipeline, it was only running in the main pipeline. We should generally catch release breakages in the nightly build. (And even those are unlikely, as the other builds should catch most breakages)
Summary
We set up a "Stripe.framework" project in Xcode Cloud, which will build the new 'ReleaseFrameworksTarget' target on release branches. All this does is run the
export_builds.rbscript and copy the results to theBUILT_PRODUCTS_DIR.The deploy script will no longer build the frameworks locally. Instead, it will fetch the artifact from the Xcode build matching the current release hash and copy it to the build products directory.
This is pretty brittle, but should be fine for our purposes. It'll also break loudly if anything fails.
Motivation
Allow us to deploy from machines running Sequoia
Testing
Tested locally. Pushed a
releases/23.test.testbranch, waited for CI to complete, then ran the first step ofdeploy_release.rb.Changelog
None