-
Notifications
You must be signed in to change notification settings - Fork 57
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
Clone the repo faster in Buildkite #6008
Conversation
4ca8212
to
cd9e83f
Compare
Wanna run full suite of Android and iOS UI tests? Click here and 'Approve' CI job! |
@mokagio, 👋 , following the ping here, I wanted to provide some further context. We noticed that the Error log here
|
@mokagio For the record, I would not recommend to use shallow clones, as from experience it often leads to edge cases in some git operations that become hard to debug. Which might explain the errors that Siobhan is seeing above. What I would recommend instead to speed up git clones is to use our git cache mechanism that we use for our other repos, i.e.:
|
🤦♂️ the Thank you for the suggestion @AliSoftware. See |
By default, Buildkite runs a
git clone
that fetches the entire repository history, for the main repo as well as the submodules (e.g.git clone -v -- git@github.com:wordpress-mobile/gutenberg-mobile.git .
)This approach is too slow for a huge repository like ours. A faster strategy is to run a shallow clone,
git clone --depth=1 --shallows-submodules
. Buildkite allows doing this via environment variables and the environment hook, but our CI configuration blocks that for security reason.I'm not sure what is the safest and more robust way to move forward. In the meantime, I found a plugin that allows setting those environment variables and copied the approach into a plugin under our org. The reason for having our own plugin instead of relying and contributing to a community one is that it seems a safer approach. Hat tip @crazytonyli for pointing this out.
The screenshot shows a gain of more than 1 minute during checkout.
Testing
Green CI is enough here.
Alternatives
I guess something we could do is make the behavior implemented in the plugin the default in our Buildkite agents setup. Maybe this has never come up because the git checkout has never been a big problem in other repos.
In the meantime, this does the job in the context of this pipeline.
PR submission checklist: