I once reduced the speed of our test suite from 10 mins to Then bcrypt work factor! It was originally 12, reduced it to 1 (don’t worry, production is still 12)
A one-line change decreased our build times by 99%
231–240 of 256 posts
Re: A one-line change decreased our build times by 99%
#232Better title: A one-line change decreased our "git clone" times by 99%. It's a bit misleading to use "build time" to describe this improvement, as it makes people think about build systems, compilers, header files, or cache. On the other hand, the alternative title is descriptive and helpful to all developers, not only just builders - people who simply need to clone a branch from a large repository can benefit from t…
Right, from the article: "This simple one line change reduced our clone times by 99% and significantly reduced our build times as a result." So the title is just completely wrong.
There's also this part of the article:
"We found that setting the refspec option during git fetch reduced our build times by 99%."
So, the article contains contradictions.
Re: A one-line change decreased our build times by 99%
#233Is there any way to do this for GitLab CI [1]? I'm using GIT_DEPTH=1, but I'm not sure how to set refspecs. It's not too important right now since it only takes about 11 seconds to clone the git repo, but maybe it's a quick win as well. [1] https://docs.gitlab.com/ee/ci/large_repositories/
Checkout the docs here https://docs.gitlab.com/ee/ci/yaml/README.html#git-fetch-ext... GIT_FETCH_EXTRA_FLAGS accepts all options of the git fetch command
Thanks for that link - seems to be further evidence they do already do this refspec flag by default.
> The default flags are:
GIT_DEPTH.
The list of refspecs.
A remote called origin.Re: A one-line change decreased our build times by 99%
#234Earlier quoted context omitted.
> If there's a step in your build pipeline that takes an unreasonable amount of time, it's worth checking why. In my current project, the slowest part of our build pipeline is the Cypress tests. (They're also the most unreliable part.) Would you say the (slow and unreliable) Cypress tests are worth it still?
I don't know. We need some sort of e2e tests, and all e2e test frameworks are terrible in one way or another. Cypress is okay. I would prefer to only run it on production or the dev server and have alarms go off when they fail, but either the requirement is, or other developers have decided that it's necessary to pass all e2e tests before a feature branch can be merged into the master branch. And I get the reason for…
We had similar issues with integration tests, and made them a separate jenkins job that didn't trigger automatically, but gitlab was still configured to require them to pass for merge. We would kick it off manually only after all other code review was complete. Then the only cases where we had to re-run it were the same cases where it would have failed in master if we only ran the test there, but it saved us the hassle of reverting or feeling pressured to get hotfixes into master quickly.
Re: A one-line change decreased our build times by 99%
#235I'm a git noob, so I'm sorry if this sounds dumb but wouldn't
git clone --single-branch
achieve the same thing (i.e, check out only the branch you want to build) ?
Also, why would you not only check out one branch when doing CI ?
Re: A one-line change decreased our build times by 99%
#236He says that "Pinboard has more than 350K commits and is 20GB in size when cloned fully." I'm not clear though, exactly what "cloned fully" means in context of the unoptimized/optimized situation.
He says it went from 40 minutes to 30 seconds. Does this mean they found a way to grab the whole 20GB repo in 30 seconds? seems pretty darn fast to grab 20GB, but maybe on fast internal networks?
Or maybe they meant that it was 20GB if you grabbed all of the many thousands of garbage branches, when Jenkins really only needed to test "master", and finding a solution that allowed them to only grab what they needed made things faster.
I'm also curious about the incremental vs "cloning fully" aspect of it. Does each run of Jenkins clone the repo from scratch or does it incrementally pull into a directory where it has been cloned before? I could see how in a cloning-from-scratch situation the burden of cloning every branch that ever existed would be large, whereas incrementally I would think it wouldn't matter that much.
Re: A one-line change decreased our build times by 99%
#237Earlier quoted context omitted.
I'd be interested to know how they came to realize what was missing. Did they read the Jenkins docs more thoroughly? Post on a mailing list? See something on StackOverflow? Hire a consultant?
I would bet on "the new recruit found it, 45 minutes in in the onboarding process".
I think everyone has done this, sometimes it really does take a second set of eyes
Re: A one-line change decreased our build times by 99%
#238Troubleshooting CI/CD feels like troubleshooting a printer: What the hell is it doing now and why is it doing that?!
Re: A one-line change decreased our build times by 99%
#239> In the case of Pinboard, that operation would be fetching more than 2,500 branches. Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?
monorepo culture.
Re: A one-line change decreased our build times by 99%
#240I think it takes some real humility to post this. No doubt someone will follow up with an “of course...” or “if you don’t understand the tech you use...” comment. But thank you for this. It takes a bit of courage to point out you’ve been doing something grotesquely inefficient for years and years.
I'd be interested to know how they came to realize what was missing. Did they read the Jenkins docs more thoroughly? Post on a mailing list? See something on StackOverflow? Hire a consultant?
The same way it always happens to me: Over time build time creeps up and you don't really look at this code thinking "I implemented shallow clone years ago so there is nothing I can do, it's slower because we have more code."
Until you or some other person looks what the code is doing.
It could also be that it was a new hire. I shallow clone a huge monorepo similar in commits/branches and it takes seconds. My experience would instantly tell me that something is worth looking into.