WIP - Use xcodes in CI with Fastlane

[mokagio]

Things that need to happen before working on this PR again:

• See how Fastlane will react in terms of using xcodes now that Apple requires authentication for downloads
• Upgrade CI to Xcode 14.1 stable, which will include xcodes

[wpmobilebot]

You can test the changes from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr8131-7881a04 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[mokagio]

[AliSoftware]

Quite "original" to implement this as a hooks/pre-command, as opposed to include the check in each of the relevant .buildkite/commands/*.sh scripts of this repo like we usually do for hacks (e.g. for the hack we did to fix the bundle double-default version and the likes). Haven't thought of that approach.

<braindump>

On one hand, implementing it as a pre-command is nice because you don't have to duplicate the check and logic in each .buildkite/commands/*.sh. On the other hand, that means that every command will run that check, even if we have some commands that might not need it (e.g. the command from the cache-builder.yml scheduled build that just rebuilds the git cache, or if we add some additional steps and commands to our pipelines in the future like ones that do some ruby linting or Danger or similar that won't really need a specific Xcode image… or lanes that don't explicitly call xcversion / xcodes and thus don't really need for it to be installed…).

Sure, in your current implementation you run it for all commands but them check if the agent is a Mac, and as you document in your comment, I know it's a temporary hack until we provision the tool in our next VMs, which will then make such a local check unnecessary, so that might not be that big a deal I guess. But this being in a separate file and not in the pipeline config files where we edit and change the IMAGE_ID might make it harder to remember to remove the hack the next time we update the IMAGE_ID and point to a VM that would now have the tool provisioned?

</braindump>

[crazytonyli]

FYI, I've added "xcodes" into the xcode-14.1 image I'm building, which should be available in a couple of hours.

[mokagio]

@crazytonyli

FYI, I've added "xcodes" into the xcode-14.1 image I'm building, which should be available in a couple of hours.

Excellent. That really makes the need for this redundant. I'll just wait for the 14.1 image to be out, upgrade, and only then do the migration to xcodes.

I don't think we should worry too much about backward compatibility in this context.

[mokagio]

@AliSoftware

Quite "original" to implement this as a hooks/pre-command,

I'll take that as a compliment. LOL.

Yes, I was curious to see how the setup worked and took it out for a spin.

I think the waste for the steps for which the check would fail is negligible because of how many more builds on macOS we run compared to the others.

The danger of the check ending up forgotten because it's in its own file out of the way is a strong one.

All in all, I think the best course of action is to wait for the 14.1 image to be out and avoid adding any of this overhead. See comment above.

[AliSoftware]

Yeah also note that, as we just learned that Apple removed the ability to download Xcode without being authenticated, I'm wondering if this would affect fastlane potentially un-deprecating the old xcversion actions and the like.

The way we use xcodes in our use case shouldn't be impacted by this new limitation, because we only use it to check the version not to install it if not present. So we should be fine.
But that new limitation for the majority of other users of xcodes might either trigger a new major version of xcodes very soon, or make fastlane change strategies or backtrack a bit if that becomes a bigger problem for the other usages of this action… which then would impact our usage despite not using it for installs?

[mokagio]

@AliSoftware

Yeah also note that, as XcodesOrg/xcodes#243 (comment), I'm wondering if this would affect fastlane potentially un-deprecating the old xcversion actions and the like.

I didn't know that... 😞

Apple being Apple as usual... 🙄 Really the fact that they don't ship an xcodes CLI themselves is embarrassing. </rant>

Probably worth parking this and observe what Fastlane does... Which work in our favor in a sense while we roll out the new CI image.

[mokagio]

I don't know if GitHub sends notifications when the PR description changes, so here's a comment to note that I tracked the things needed before considering resuming work on this in the descrption:

Things that need to happen before working on this PR again:

• See how Fastlane will react in terms of using xcodes now that Apple requires authentication for downloads
• Upgrade CI to Xcode 14.1 stable, which will include xcodes

[AliSoftware]

Additional note: while I initially thought that this new need for authentication wouldn't impact us because we don't use xcodes for installing Xcode but only for checking… Someone on the fastlane Slack rightfully mentioned that it might still impact us… if we're telling xcversion / xcodes to also update the list of Xcode versions 🤔
Eh, let's wait on how things go and revisit when the dust settles.