Build and upload prototype build from CI

[mokagio]

Description

Adds the automation necessary to build a prototype builds in CI and upload it to App Center

Testing Steps

Check out the latest Buildkite build and the bot comments in this PR

Notice that the icon is the old one because this branched from #326 before #329 landed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Gravatar SwiftUI Prototype Build by scanning the QR code below to install the corresponding build.

	App Name	Gravatar SwiftUI Prototype Build
	Build Number	1053
	Version	1.0
	Bundle ID	com.automattic.gravatar-sdk-demo-swiftui.prototype-build
	Commit	8fe87fd6cf93763c9a2bef2fd22625ea6012e87f
	App Center Build	Gravatar SDK Demo - SwiftUI #7

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Gravatar UIKit Prototype Build by scanning the QR code below to install the corresponding build.

	App Name	Gravatar UIKit Prototype Build
	Build Number	1053
	Version	1.0
	Bundle ID	com.automattic.gravatar-sdk-demo-uikit.prototype-build
	Commit	8fe87fd6cf93763c9a2bef2fd22625ea6012e87f
	App Center Build	Gravatar SDK Demo - UIKit #7

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[andrewdmontgomery]

❓ Question

Is it possible to have these prototype builds only happen when the PR has a specific label?

It occurred to me this morning that, since that this repository is public, and these prototype builds are only available to Automatticians, their presence in PR's could be mildly confusing. There are a few ways we could handle that confusion (and I'm a big fan of a layered approach to this, delivering both of these if we can):

• Explain it in the copy of the automated PR comment
• Only build prototypes when we need them

That second point is the one I'm wondering about. If we can limit prototype builds to just the PR we label prototype build (for example), then:

• 95% of our PR builds won't produce a prototype build (no confusion)
• And the rest could have copy that briefly describes something like "Automattic internal use only"

If, on the other hand, those PR labels aren't available to BuildKite, then I think we keep them on every build and just focus on documenting their limited availability. I believe the ease-of-use of having these builds available to non-developers (without any extra steps) outweighs any worry about public confusion over them.

[andrewdmontgomery]

@mokagio I should clarify. Don't let this question (above) block this PR. We are happy to iterate, and we're eager to get these prototype builds into the hands of our designer.

[AliSoftware]

Is it possible to have these prototype builds only happen when the PR has a specific label?

Using GitHub labels as conditionals for build jobs is a tricky thing and not ideal (at least in Buildkite), because:

• If the CI build has already started by the time you decide to add the label to your GitHub PR, that won't suddenly be detected and trigger the job after the fact. So it'd only work effectively if you happen to add your label while you write you PR description but before you hit the button to create the PR (and thus trigger the build); or if you push a new commit (thus triggering a new CI build for it) after you added the label to the PR.
• Indeed, Buildkite doesn't listen to label-added/label-removed webhook events by default, so it can't react to the event of adding/removing a label to a PR to suddenly decide to retry/re-trigger a job
• In practice there is an option in Buildkite to trigger a new build on the label-added/label-removed webhook events; but that have the effect of triggering a new build from scratch upon reception of said event, similar to when you push a new commit. Which means that:
  • It will rebuild all the jobs of the build (including lint, build-and-test, etc) not just the job doing the Prototype Build
  • and it will do that regardless of the label that was added/removed (so if you add a label like tooling or bug to your PR, it will trigger a new build only to realize that's a label we don't care about in the context of doing a Prototype Build or not

So TL;DR: using PR labels for conditionals on CI jobs has a lot of side effects and edge cases to consider and is thus usually not the best solution for this kind of need.

---

What we could do instead if we wanted to only trigger Prototype Builds on certain PRs but not by default, is to make the condition be on the PR title, or on the branch name. For example, at Beeper-Desktop, they decided to only generate testable builds if the branch name starts with build.*.

Relying on the PR title would still have the same quirk as with labels wrt to live-detecting a change though: if you open your PR without the magic word in its title in the first place, editing the PR's title after the fact won't suddenly make Buildkite detect it nor trigger a Prototype build automatically: you'd still have to push a new commit after changing the PR title (or use the Rebuild button on the last build on Buildkite' UI) for it to take the change into account. But arguably changing the title of a PR is less common than adding a label. Still a tradeoff though.

---

In the end I think building the Prototype Build unconditionally on all PRs is OK; besides, we've configured the PR comment to be folded by default (i.e. the QR code is hidden within a <details>…</details> block) so hopefully that doesn't create too much noise?

[AliSoftware]

Hi @pinarol @andrewdmontgomery ! I took the liberty to update the PR to fix the lastest quirks I saw in CI (typo on Gavatar-SwiftUI-Demo.Release.xcconfig file name, removed .xcconfig file from Build Phase, fix incorrect artifact basename used by appcenter_upload when referencing .ipa and .dSYM.zip) to make the Prototype Builds job finally succeed.

Can you do a last confidence check by validating that the QR code on the two comments above (here and here) work, that you're able to install the Prototype Builds on your device, and that they work as expected?

If so I think we can finally merge this PR (we can always address potential adjustments in follow-up PRs if needs be anyway)

[pinarol]

I have installed both builds via AppCenter successfully 🎉 :shipit:

[pinarol]

Thank you very much! I'll merge.

[AliSoftware]

WDYT about completely removing the "Build Demo Projects" job from the pipeline.yml […] at some point?

Followed-up on this in https://github.com/Automattic/Gravatar-SDK-iOS/pull/348

Is it possible to have these prototype builds only happen when the PR has a specific label?

PS: @andrewdmontgomery note that with https://github.com/Automattic/Gravatar-SDK-iOS/pull/348 removing the "Build Demo Project" job—in favor of the compilation of those Demo projects being validated by CI by the fact that the Prototype Builds for those Demos are being build and would surface any compilation issue on them there anyway—it now makes even more sense to build those Prototype Builds unconditionally (and avoid skipping them based on labels or whatnot, otherwise we'd also not validate correct compilation of the demos) 🙃

[mokagio]

Thanks for bringing this home @AliSoftware 👏

While it's a team workflow decision, my two cents on the Prototype Builds is that it's worth building them unconditionally, also. CI Compute and storage are cheap compared to the value of the feedback we get from those builds. And notice that the feedback occurs not only when someone installs the build but also when the build builds.