The build I’m running currently takes 25-29 minutes to build. This is quite longer than what we’re used to building on local Mac Mini devices (12 min).
Is this due to using the free plan, or is this performance expected?
3 Likes
In general it’s expected that the build will be slower than on your Mac, because the build you do on Bitrise is a more complete build.
Every build which you run on bitrise.io runs in a completely clean environment. On your local Mac you have lots of caches, which can speed up the build but can also affect the results. For example it’s possible that the project builds on your Mac, but then it won’t on another. With Bitrise (with ephemeral build environments in general) you can be sure that if the build passes on Bitrise, your repository includes everything required for the build on any Mac.
You can find more information here: http://devcenter.bitrise.io/faq/why-my-build-takes-longer-on-bitrise-than-on-my-mac/
You’re of course free to use the Build Cache feature to improve the build times, but that can affect the result of your build, just like the caches on your local Mac.
If you want to, feel free to share more about your project (e.g. is it a native iOS project? Or a Xamarin one? Which step(s) take a long time?) and we can try to help with suggestions to improve the build time, but every speed improvement solution - like the Build Cache - has its own pros & cons.
It’s a native iOS project that I’m building using Fastlane.
The build running on Bitrise is significantly slower than our local CI machine, which is a Mac Mini running dedicatedly for the purpose. Locally, it takes 13 minutes to run, complete with git checkout and upload. On Bitrise, only the Xcode archive step takes a whole 20 minutes.
Locally, it takes 13 minutes to run, complete with git checkout and upload. On Bitrise, only the Xcode archive step takes a whole 20 minutes.
That’s most likely because of the system (Xcode) caches: http://devcenter.bitrise.io/faq/why-my-build-takes-longer-on-bitrise-than-on-my-mac/#local-build-caches
On bitrise.io these caches are not available as the environment is always completely clean (it’s the same as a clean macOS install with Xcode installed on it). This ensures that if the project can be built in this environment, then it can be built on any other Mac; that your repository includes everything required for a successful build.
Hi! I’m new to Bitrise but I’m having an issue I think you could help me. I have a swift/ios project with cocoapods and the step xcode-test@1.18.3 is taking at least 477 seconds to run!
I have my frameworks/pods uploaded but it seems that they are being compiled again each and everyone of them
Is there a way to reduce this time? Especially because what I now have are 17 tests that take less that a second to execute
primary:
steps:
- activate-ssh-key@3.1.1:
run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
- git-clone@3.4.3: {}
- cache-pull@0.9.2: {}
- cocoapods-install@1.6.1: {}
- certificate-and-profile-installer@1.8.5: {}
- recreate-user-schemes@0.9.5:
inputs:
- project_path: "$BITRISE_PROJECT_PATH"
- xcode-test@1.18.3:
inputs:
- is_clean_build: 'yes'
- cache-push@0.9.4:
inputs:
- cache_paths: "./Pods -> ./Podfile.lock"
- deploy-to-bitrise-io@1.2.9: {}
- slack@2.3.0:
inputs:
- webhook_url: https://hooks.slack.com/services/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
- channel: "#devbot"
- message: Build Succeed
- message_on_error: Build Failed
- icon_url: ''
- icon_url_on_error: ''
Thanks for all the help you can give me 
1 Like
That’s a reasonable time I’d say, as this step’s purpose is to test your project as much as possible. For more information please read my answer below
So the thing is that yes, your tests can run in a couple of seconds if the project is compiled and there’s a fully booted iOS Simulator and your test app is installed in it.
But these are exactly the things you want to avoid when you do Continuous Integration, usually, to have a complete test as much as possible.
When you run your build on bitrise.io every build runs in a clean virtual machine. This is pretty much the same as if a new colleague would join your team with a clean MacOS install, and wants to do a full build+test on that Mac the very first time. It’d most likely take about the same time for a Swift project, even on a MacBook Pro, to compile + boot the simulator + install the app in the simulator + run the tests.
There are a couple of things you can try to speed up things, but there are always pros & cons.
- Probably the easiest one is to turn off the (Experimental) Wait to simulator boot? option of the Xcode Test step. Why is this turned on by default? Because the iOS Simulator can be unreliable, where it simply fails to properly boot for test / run the test. Would this affect your tests? Depends. Newer Xcode versions improved things quite a bit, but there are still quite a few edge cases we saw where pre-booting the iOS Simulator before starting the tests improves the reliability of the tests. But this might help, and is easy to try.
- Caching things. Now the thing about this is that you can speed up things quite a bit usually, but caching means that a previous build can affect subsequent builds. E.g. caching DerivedData where Xcode generates its build caches definitely can help, but this means that when your next build starts it’ll have the build file caches from the previous build. Did you change Xcode version between the two builds? Did you add or remove dependencies? Did you add/remove a
.gitignore? These (and many other “edge cases”) can all cause issues.
There are probably other things worth to try, you can search for tips here on discuss.bitrise.io, but unfortunately there’s no “silver bullet”. All of the “tricks” to speed up a build either can result in flaky tests (less reliable) or cause false positives & false negatives (where a previous build’s cached build intermediates either make or break the build, when with the current code it should not). Of course tread offs might worth it in your case, that’s up to you to decide, we strive to provide the most reliable solution out of the box, configured to run the fastest possible (priority is: stability > speed; but we do try to make things as fast as possible, we just don’t compromise about reliability).
P.S.: there’s one more thing which is guaranteed to speed up things, our Elite plans which use more powerful hardware (Mac Pros in case of the Mac stacks), but cost more. You can find more info about these at Pricing and Plans for Mobile DevOps - Bitrise - if you’re interested we’re happy to activate a trial.
1 Like
Just one more note specifically for this: adding new tests won’t slow down the build additionally!
The slow things are “already there”. The Simulator won’t boot slower because you add new tests, it’ll take the same amount of time (roughly).
Of course a larger code takes more time to compile, but that’s the same as on your Mac, the diff is about the same as on your Mac (if you do a clean build right now vs with a more complex code later).
Awesome!! I understand now. I’ll probably leave it as it is then since I understand the whole purpose.
One other thing, do you know if there is a difference on running times if the project had carthage instead of cocoapods?
Thanks for the information, it has been most useful!
Carthage in general is slower than CocoaPods, from a build/CI perspective, but can be cached efficiently - we’ll improve the related caching in the coming weeks too.
The difference depends on your configs, so I guess “it depends” and I’d say it worth a try, on a “throw away” branch in your repo, so that you can compare those 
One more thing: if you’d need just a bit more build time, feel free to ping us through email / the onsite chat. If it’s a personal project we’re more than happy to bump the limits a bit (if that would be a concern).
1 Like
Excellent! Thanks for all the insights!
1 Like
Our bitrise build time is taking a lot of time for the archiving step. It is around 550-600 seconds. Can this be optimized?
Hi @ajhawar,
Which step? Xcode Archive?
Thats correct Viktor!
Do you have Bitcode enabled and do you archive for the App Store?
If you do, that’s the slowest combination, as in that case Xcode will have to build multiple different ~versions of the app.
This discussion has some details too:
http://discuss.bitrise.io/t/builds-slow-any-solution-to-speed-it-up/61
Thanks Viktor! … So should I have this setting?
Select method for export : Development
Include bitcode : NO
Rebuild from bitcode : NO
Correct, that might help to speed it up.
Also git clone is consuming considerable time.
We have already updated the setting to fetch till depth 1. But can we further optimize to fetch only the specified branch.
This is what we get from logs
=> git “init”
=> git “remote” “add” “origin” “GIT_REPO_URL”
=> git “fetch” “–depth=1”
=> git “checkout” “develop”
=> git “submodule” “update” “–init” “–recursive”
May be something like this
git fetch --depth=1 <remote_name> <branch_name>
If you use depth=1, that’s pretty much as fast as you can get. Or do you know about a trick which could make it faster?