-
Notifications
You must be signed in to change notification settings - Fork 1k
threads through --no-history flag enabling faster cloning using gclient #29938
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
Warning You have got a presubmit warning. Please address it if possible.
Items:
|
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.
this is fine for local development, but we can't (and shouldn't) do this for CI. brave/brave-browser#6444 (comment)
CI is already optimized by using git cache along with chromium.googlesource.com to bootstrap most git repos with git packs in a very efficient way.
please make yourself familiar with git cache that depot_tools is using https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/0d6837383d9dd5c8b2ecd21f5b5c5f124c5cca31/git_cache.py#266
you can greatly optimize the initial init speed for local development by following these two recommendations:
https://github.com/brave/devops/wiki/Faster-browser-builds#git
https://github.com/brave/devops/wiki/%60.env%60-config-for-Brave-Developers#fetching-chromium-from-googlesourcecom-instead-of-githubcom
Yes I agree and I'm familiar, hence I mention that it's probably only appreciated by external contributors. |
One way of doing this is to enforce git cache and switch chromium repo from github to googlesource. This way it will always be bootstrapped. |
Chromium major version is behind target branch (138.0.7204.97 vs 139.0.7258.32). Please rebase. |
Released in v1.82.126 |
Resolves: brave/brave-browser#6444
threads through --no-history flag enabling faster cloning using gclient.
GClient currently clones a total of 230 repositories with their complete history.
We can speed up this process by passing --no-history flag to gclient.
This PR is just an enablement and doesn't change the default behaviour.
I didn't com accross any failures when patches were applied but we may be lucky beause
apply currently doesn't need to resort to the index line of a patch?
My local test conclude a reduction of downloaded data from 99GB -> 23GB.
This may not be a huge improvement on CI but may be appreciated by external contributors.
There are a few tools in our scripts folder eg. git-bisect that may not work on a shallow clone but this is not necessarily meant for full-time devs