-
Notifications
You must be signed in to change notification settings - Fork 120
[Tooling] Update Xcode version refs in tooling scripts #8033
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
Conversation
In `.xcode-version` and `Fastfile`
You can test the changes from this Pull Request by:
|
And thus also allowing future 14.x versions after 14.0
| @@ -0,0 +1 @@ | |||
| ~> 14.0 | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file we had before was .xcversion, but the file used by Fastlane's xcversion action is supposed to be named .xcode-version (by convention similar to files like .ruby-version and the like), not .xcversion, hence this file rename (in addition to updating its content to ~> 14.0).
mokagio
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm downloading Xcode 14.1, so in the meantime here's some notes and a preemptive approval.
| # Be sure to also update the `.xcode-version` file when updating the Xcode image/version here | ||
| IMAGE_ID: xcode-14 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great addition 👍
In the past, I used dynamic pipelines, where instead of having an hardcoded YAML pipeline we'd run a script that generated the YAML at runtime. In that setup, we could read .xcode-version and generate the IMAGE_ID name based on it.
But, dynamic pipelines are harder to read, might have bugs in the generation logic, and we don't change Xcode versions that fast to justify the investment and tradeoff at this point in time.
| unless options[:skip_prechecks] | ||
| ios_build_prechecks(skip_confirm: options[:skip_confirm], external: true) | ||
| ios_build_preflight | ||
| xcversion() # Ensure we're using the right version of Xcode, defined in `.xcode-version` file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick. Have you considered wrapping xcversion() in a function to integrate the comment in the code? Something like check_xcode_version or enforce_xcode_version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: I accidentally landed on this document that mentions xcode-install/xcversion has been deprecated and how to update to the new xcodes alternative.
Might be worth looking into before merging, or as an update followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or as an update followup.
I'd be happy to look into it if your plate's full.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh TIL this was deprecated. Yeah I'd love if you can take a look at migrating the command to xcodes. A bit unfortunate to see that it seems to require the installation of a separate tool tho, unlike xcversion…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mokagio Seems latest fastlane shipped with official new usage of xcodes over xcversion: https://twitter.com/fastlanetools/status/1591561723794030592
|
FYI, I run into some limitations when trying to use I also have a WIP PR to use |
|
Given we parked in the PR migrating things from |
👍 |

Why?
This updates the references to the minimum Xcode version needed to compile WCiOS to
14.0, as some references in.xcversionandFastfilewere still mentioning~> 13.4being the minimum, while the project now requiring Xcode 14 minimum to compile.Context
While I was trying to run the Unit Tests in my Xcode on my local machine, I encountered some issues because:
xcode-select -p) was still 13.4.1As a result, I accidentally tried to run the Unit Tests with Xcode 13.4, which failed to compile — at the very least because of this line which uses a new feature only available since Swift 5.7 — and I had to open the project with Xcode 14 to be able to compile it.
Our CI config for this project is also using Xcode 14 anyway, so this makes sense to keep those aligned.
To Test
xcversion()calls in theFastfileas working and relying on.xcode-versionfile as expectedbundle exec fastlane build_for_testinglocally and validate that it passes (i.e. it doesn't complain about Xcode 14 missing).14.0installed on your machine, but do have Xcode14.1, so that we can prove that the~>operator works as expected and does not restrict to just14.0exact match. (I personally only had Xcode 14.0 on my machine, and have wifi trouble today so not the day I'm going to download14.1to test 😅 , but hopefully someone can test on their machine).xcode-versionto something like~> 14.5, trybundle exec fastlane build_for_testingagain, and validate it complains about Xcode 14.5 or later not being found on your machine.appand delete that.appso that it couldn't be found on your Mac anymore and retry to verify it complains about not finding Xcode 14 being installed anymore… but that might take a bit long to zip / uninstall Xcode 14 then unzip/reinstall it once done, so…)