Sry … text didnt come fully … something like this
git fetch --depth=1 REMOTE_NAME BRANCH_NAME … i suppose this will be faster
Sry … text didnt come fully … something like this
Can you try that with a Script step and let us know whether that speeds it up in any significant way? I’d think that there won’t be any significant improvement over
fetch --depth=1, but I might be wrong
when running locally, I tested the default command of
git init && git remote add ... && git fetch --depth 1 vs
git clone --depth 1 ssh://... directly, and the latter is significantly faster:
# git fetch remote: Counting objects: 17610, done. remote: Compressing objects: 24% (2854/11541)
# git clone remote: Counting objects: 6369, done. remote: Compressing objects: 29% (1335/4584)
Thanks for the info @maz.careem !
Quick question, did you run these tests more than once, always in a new/clean directory? Was the diff. always around these numbers?
Thanks for the quick response. I tried running in multiple times on the same repo, always the same result. I then tried it on other repos from phabricator, and it also had a significant difference. Finally, I tried some repos from github, and most of them had a marginal difference as well.
One great example is Apple’s swift repo:
% git clone --depth=1 https://github.com/apple/swift.git ss ~/Developer/careem Cloning into 'ss'... remote: Counting objects: 12963, done. remote: Compressing objects: 100% (7692/7692), done. remote: Total 12963 (delta 5939), reused 6761 (delta 4978), pack-reused 0 Receiving objects: 100% (12963/12963), 12.99 MiB | 2.09 MiB/s, done. Resolving deltas: 100% (5939/5939), done. Checking out files: 100% (12432/12432), done.
(master) % git remote add origin https://github.com/apple/swift.git ~/Developer/careem/sf (master) % git "fetch" "--depth=1" ~/Developer/careem/sf remote: Counting objects: 51742, done. remote: Compressing objects: 100% (24558/24558), done. remote: Total 51742 (delta 39300), reused 34328 (delta 26672), pack-reused 0 Receiving objects: 100% (51742/51742), 25.35 MiB | 1.63 MiB/s, done. Resolving deltas: 100% (39300/39300), done. From https://github.com/apple/swift
Thanks for the infos @maz.careem!
I’ll schedule a review for this and if we don’t find anything what would break because of this change then we’ll implement it and publish a new Git Clone step.
Enthusiastically waiting for this, and to present to our with what a great service bitrise is providing
I agree, although as this is not a bug nor a major issue, the task got a “normal” priority on our task list.
If this is something you really really need, feel free to create a #feature-request, we do weight in the feature request votes when we plan our upcoming features/sprints.
Please consider adding the user-defined setting SWIFT_WHOLE_MODULE_OPTIMIZATION=YES flag in XCode, this will speed up compilation time drastically. Don’t let the optimisation level fool you, because that one should stay on “None”, and not be changed to “-whole-module-optimization”.
See this Hacker News thread https://news.ycombinator.com/item?id=13214431, with Uber (https://www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers) and Zalando (https://tech.zalando.com/blog/improving-swift-compilation-times-from-12-to-2-minutes/) mentioning it too.
Faster iOS build times
Xcode build time improvement ideas
WWDC 2018: “Building Faster in Xcode”: https://developer.apple.com/videos/play/wwdc2018/408/
I would not create another topic for another speed up issue but I’m stuck and I don’t know how to build faster my workflow. I already have the SWIFT_WHOLE_MODULE_OPTIMIZATION flag into my build settings.
Every step runs in few seconds but Xcode Archive takes ~30min for an AppStore build ! I can’t disable Bitcode such as our app will be too big on devices.
It’s kind anoying such we have a team plan with only one concurrency build, iOS takes a very long time by it self
Can I have some help @viktorbenei ?
Thank you very much !
We’re working on related caching improvements, which should roll out in the near future (will be built into our Xcode steps), as well as we’re in the process of upgrading all of our Mac build machines, both the Standard and Elite ones, to faster hardware in the next 1-2 weeks.
That said hardware itself isn’t that significant in case of a ~30 min Xcode Archive, I guess it doesn’t really matter if it’s 20 or 30 mins.
The caching improvements should improve that more drastically (we saw 30 -> 2-3 mins drops), but that will take a bit more time (a few weeks or months until “public beta”), it’s still in private beta/internal testing as we want to ensure it does not introduce any side-effect/issue.
Hi and thank you for the reply,
Good to know that new caching process will increase build times in the future.
But for now, is there any way to reduce archive time for production ? Even if we can “just” reduce from 30 to 20, it will be very great !
Is there a way to join the private beta?
New Macs are in production, you should see the build time reduction automatically. We’re still tweaking some configs but it should be visible.
Cool, thanks guys!