Misleading title. They reduced their clone time by 99%. Not their build time.
A one-line change decreased our build times by 99%
111–120 of 256 posts
Re: A one-line change decreased our build times by 99%
#112Earlier quoted context omitted.
I would expect that internally someone profiled the build (i.e. looked at timestamps) and then either profiled git, or just looked at the logs and did some guessing/research. This didn't seem like it would be complicated to find once you realize the time is spent in git. Also, this probably has been an exponentially increasing problem, and wasn't really a priority to solve until relatively recently. I would bet there…
It really doesn't sound complicated to find, unless you just have a handsoff approach to building things and just don't care as long as "something" comes out on the other end. What makes me wonder however is this: 40 min made them look into this? I mean 40 min is crazy long. What builds this long? Chrome, Windows, Linux Kernel on a single core? This should have been raising red flags much earlier. The only explanatio…
Remember "build" time likely also includes test runs, packaging for deployment, ... 40 mins is easy to get to, and has nothing to do with "on a single core".
Re: A one-line change decreased our build times by 99%
#113Earlier quoted context omitted.
We have not "as an industry" moved to git. There's a vocal subset of git fans, but it is by no means an industry standard.
What industry are you part of? In many domains git has replaced other version control systems. I would love to see a new approach to version control. Things like subversion or mercurial have exposed too many drawbacks for them to win back industry.
Google and Facebook both don't use git. Google uses a proprietary, perforce-esque system with multiple frontends, and Facebook uses Mercurial.
Among startups, I'm sure git holds a near monopoly, but if you move into other parts of the industry, that monopoly loosens.
Re: A one-line change decreased our build times by 99%
#114TLDR: they reduced "git clone" time on their massive monorepo by making it only check out master branch when building in Jenkins.
Re: A one-line change decreased our build times by 99%
#115Earlier quoted context omitted.
Good teams profile everything. This team's only goal is to support other engineers. Build time is a huge issue for every ops team. Missing this for so long is wasted money that's easy to calculate. We can be nice to people while still having high standards. It's a missed opportunity for a deeper postmortem, and it's bland content at best.
I think you live in a highly theoretical parallel universe. The one I occupy is the one where 'good teams' profile those things that take too long. Take yourself as an example: in spite of the wide availability of free certificates you are still hosting your domain without using a secure transport layer. Some would take that as incompetence. Others would assume you have more stuff on your plate rather than that you d…
And others would assume, that there are other philosophies out there regarding ssl everywhere. So the question is, who's POV has more validity and logical rigor attached to it. I actually can't see any side winning here on a purely logical level. Only on an ideological level. At least as long as we are talking about consuming public information.
Am I in favor of the aggressiveness of OP in other posts? No. Am I using SSL myself. Hell yes.
Nonetheless, I understand that there are people who feel that consuming public information like on a private homepage is nothing that necessitates using SSL. Even if I myself have a different ideology/value set governing my decision.
I once heard the comparison that it is like the difference of sending a letter and sending a picture postcard. Not sure if I buy into that, but I can't argue against it on a purely rational basis.
Re: A one-line change decreased our build times by 99%
#116> Even though we’re telling Git to do a shallow clone, to not fetch any tags, and to fetch the last 50 commits ... What is the reason for cloning 50 commits? Whenever I clone a repo off GitHub for a quick build and don't care about sending patches back, I always use --depth=1 to avoid any history or stale assets. Is there a reason to get more commits if you don't care about having a local copy of the history? Do auto…
Tags. All of my builds use `git describe` to get a meaningful version number for the build.
Re: A one-line change decreased our build times by 99%
#117This is the most I've ever gotten out of pinterest, other than this, it's just the "wrong site that google turns up, that I can't use because it wants me to create an account just to watch the image I searched for"
Re: A one-line change decreased our build times by 99%
#118We recently reduced our build times by 5-10% or so by changing the default bcrypt iteration count (for tests). It also felt silly once we found it.
Re: A one-line change decreased our build times by 99%
#119This is the most I've ever gotten out of pinterest, other than this, it's just the "wrong site that google turns up, that I can't use because it wants me to create an account just to watch the image I searched for"
The most frequent search keyword that I use is "-pinterest"
Re: A one-line change decreased our build times by 99%
#120Earlier quoted context omitted.
They set out to reduce build times, not to reduce git checkout times. It turns out that 99% of the entire build was spent downloading code.
Where does the article say "99% of the entire build was spent downloading code"?
It quotes a jenkins job going from 40 minutes to 30 seconds.