Enable Swiftsyntaxt prebuilds

[isabelrios]

📜 Tickets

Jira ticket
Github issue

💡 Description

Now that we're on Swift 6, let's try to add  CLI arguments to the build step

🎥 Demos

Before	After

Demo

📝 Checklist

• I filled in the ticket numbers and a description of my work
• I updated the PR name to follow our PR naming guidelines
• I ensured unit tests pass and wrote tests for new code
• If working on UI, I checked and implemented accessibility (Dynamic Text and VoiceOver)
• If adding telemetry, I read the data stewardship requirements and will request a data review
• If adding or modifying strings, I read the guidelines and will request a string review from l10n
• If needed, I updated documentation and added comments to complex code

[mobiletest-ci-bot]

🧹 Tidy commit

Just 1 file(s) touched. Thanks for keeping it clean and review-friendly!

✅ New file code coverage

No new file detected so code coverage gate wasn't ran.

Generated by 🚫 Danger Swift against d159c09

[isabelrios]

Trying this here because we would also like to reduce build time when building locally...

[adudenamedruby]

I don't know if I'm comfortable with this (specifically here, in the bootstrap), because it's changing defaults on the user's machine, and, as an open source project, we do have a bit of a responsibility to not meddle with a user's machine for our own repo's sake. I'd love to get the rest of the tech-lead's opinion on this. I will ping. :)

[adudenamedruby]

As an alternative, we could explore passing in an argument to this script that does this? Or, better yet, fxios as I'm going to deprecate this script soon in favour of fxios?

[lmarceau]

because it's changing defaults on the user's machine

Yeah I agree, I think it's best not to touch user's machine since a lot of people/contributors will run this script 🤔

[isabelrios]

yeah... agree... there might be other options to make the flag available on build time locally when building to save compilation time.. I could not think of other ways but if you think there are other options, please let me know!

[OrlaM]

We could update the bootstraps script to take an argument to enable prebuild packages or not, default to not if the argument is not included. That way CI can use it but for everyone else it's optional.

I'm still a little nervous of that approach because it means XCode will work differently for some which can result in taking longer to track down some build issues but if the build time improvement is significant it could still be worth it. What kind of difference are we looking at?

[isabelrios]

Swift Macro (CopyWithUpdatesMacro) that depends on Apple's swift-syntax package was added, this has a large codebase so recompiling it from source every time you clean the build folder consumes a considerable amount of time.
On CI we saw the increase build time issue that luckily was fixed thanks to the cache feature being enabled, still we can add the step included in this PR to make sure in CI we are not rebuilding everything.
I was wondering if there is something we could do to also improve that when building locally if it has been an issue for people lately due to the time it takes now to build. If that is fine, then we may not need anything here

[ih-codes]

Could we not use the command line arguments for the build process just in the CI instead of setting the local xcode configuration? 🤔 (reference)

[adudenamedruby]

Personally, I'd prefer to be explicit about this, and actually have these flags in the commands vs having a basically hidden default. Especially if we're gonna bake this into fxios, it'll make it easier to debug things equally.

[isabelrios]

I am undoing this change

[ih-codes]

@isabelrios I noticed the build step on this PR in Bitrise took 12m 50s... is that showing any improvement with the prebuilt? 👀

[isabelrios]

@isabelrios I noticed the build step on this PR in Bitrise took 12m 50s... is that showing any improvement with the prebuilt? 👀

not really from what I can see after two runs.. so maybe with the cache we don't need this

[ih-codes]

@isabelrios I noticed the build step on this PR in Bitrise took 12m 50s... is that showing any improvement with the prebuilt? 👀

not really from what I can see after two runs.. so maybe with the cache we don't need this

@isabelrios Interesting, yeah the cache would probably help improve this exact scenario with the Swift macro compile times. 🤔 I have 2 potential ideas to test prebuilts/cache:

• You had a draft PR where you tested the pipeline after reverting my Swift Macro. We could try re-running that revert pipeline now that caching is enabled. If we get the same build times as on main, then the cache is a "solution" for the macro.
• To test the prebuilts in this PR specifically, we could temporarily disable the Bitrise cache for just this PR's pipeline (but I'm not sure if disabling the cache like that is even possible 😅 ). But if we run this one with and without the cache and compare against old build times, hopefully we would see if the prebuilt flag does anything...

Have we returned to lower build times now overall with caching enabled, or are we still high enough to be concerning lately...?

[isabelrios]

@isabelrios I noticed the build step on this PR in Bitrise took 12m 50s... is that showing any improvement with the prebuilt? 👀

not really from what I can see after two runs.. so maybe with the cache we don't need this

@isabelrios Interesting, yeah the cache would probably help improve this exact scenario with the Swift macro compile times. 🤔 I have 2 potential ideas to test prebuilts/cache:

You had a draft PR where you tested the pipeline after reverting my Swift Macro. We could try re-running that revert pipeline now that caching is enabled. If we get the same build times as on main, then the cache is a "solution" for the macro.

I can try that, yes, although I am not sure I can get that on top of latest main.

To test the prebuilts in this PR specifically, we could temporarily disable the Bitrise cache for just this PR's pipeline (but I'm not sure if disabling the cache like that is even possible 😅 ). But if we run this one with and without the cache and compare against old build times, hopefully we would see if the prebuilt flag does anything...

I don't think we can disable cache for just one pipeline... I can try to modify the bitrise steps here so that those are ignored but not sure if that would work.

Have we returned to lower build times now overall with caching enabled, or are we still high enough to be concerning lately...?

Yes, you can see the blue line in this graph dropping to our regular values...
We are a bit over than at the beginning of the year but mostly to the increase in running unit tests workflow

[github-actions]

This PR has been automatically marked as stale. Please leave any comment to keep this PR opened. It will be closed automatically if no further update occurs in the next 7 days. Thank you for your contributions!