A one-line change decreased our build times by 99% • Hacker News Board

Re: A one-line change decreased our build times by 99%

#221

Post by mcv » Mon, Oct 26, 2020, 2:12 PM UTC

Cthulhu_ wrote: post #217

holtalanm wrote: post #205

Earlier quoted context omitted.

> In my current project, the slowest part of our build pipeline is the Cypress tests Oh man, I feel your pain.

Personally I think longer tests (like a full Cypress run) should not be a boundary to merging in prod if they take more than 10 minutes, but should be run nightly or continuously in the background. I've not yet had the opportunity of having a large Cypress suite (working on it as we speak), but is it still more stable than e.g. Selenium is? Honestly 80% of issues we had with that were 'unstable' tests.

Exactly. I would much prefer a setup like that over our current rule that all cypress tests must pass before merging.

A better rule might be that at least one unit or e2e test was added or updated to reflect the change in the code, and that that particular test succeeds. But run all the others on master.

One advantage (or occasional disadvantage) of Cypress test before merging, is that there is someone clearly responsible for fixing it if a test fails. Problem is, sometimes the failing test has nothing to do with anything the creator of the pull request did. It's still a mystery how that's possible, but it happens. Hence my feeling that Cypress tests aren't very reliable. At least some of ours aren't.

Re: A one-line change decreased our build times by 99%

#222

Post by rovr138 » Mon, Oct 26, 2020, 2:17 PM UTC

dahfizz wrote: post #200

SamuelAdams wrote: post #189

> 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?

Where I work doesn't delete branches, because there is no reason to. Git branches have essentially zero overhead and deleting them is just extra complexity in the CI toolchain. Deleting branches also deletes context in some scenarios. When dealing with an old codebase its nice to be able to checkout the exact version of the code at some point without having to dig through the log to get hashes and then dealing with a…

> Git branches have essentially zero overhead

Based on the article linked here, they do.

Re: A one-line change decreased our build times by 99%

#223

Post by paytonburd » Mon, Oct 26, 2020, 2:21 PM UTC

nathan_f77 wrote: post #125

Is 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

Re: A one-line change decreased our build times by 99%

#224

Post by dahfizz » Mon, Oct 26, 2020, 2:22 PM UTC

rovr138 wrote: post #222

dahfizz wrote: post #200

Earlier quoted context omitted.

Where I work doesn't delete branches, because there is no reason to. Git branches have essentially zero overhead and deleting them is just extra complexity in the CI toolchain. Deleting branches also deletes context in some scenarios. When dealing with an old codebase its nice to be able to checkout the exact version of the code at some point without having to dig through the log to get hashes and then dealing with a…

> Git branches have essentially zero overhead Based on the article linked here, they do.

> If you have a weird branching strategy where you maintain multiple, significantly diverged branches at once, but only care about one of those branches at build time, then this optimization would save you time.

Its not the fact that they had lots of branches itself, its the fact that they had lots of commits hanging out in the middle of nowhere.

Re: A one-line change decreased our build times by 99%

#225

Post by uglycoyote » Mon, Oct 26, 2020, 2:25 PM UTC

pavel_lishin wrote: post #49

hashkb wrote: post #45

Earlier quoted context omitted.

In general I'm frustrated that rigor, standards, etc are out the window in favor of all this warm fuzziness. I guess I might be angry... The culture change in our industry, towards warm fuzzies and away from tech screens, results in calculable waste. Time, money, electricity, customers. We lose good engineers and tell ourselves they were a bad fit. We push crap on users just to sell ads. Then we write engineering pos…

> The culture change in our industry, towards warm fuzzies and away from tech screens, results in calculable waste. I have not noticed, in the past decade, any move away from tech screens whatsoever.

Are we talking about technological screens, like LCD screens here?

Re: A one-line change decreased our build times by 99%

#226

Post by joshribakoff » Mon, Oct 26, 2020, 2:41 PM UTC

Misleading title. They reduced git clone time 99%, not build times.

Re: A one-line change decreased our build times by 99%

#227

Post by JoeAltmaier » Mon, Oct 26, 2020, 2:42 PM UTC

So git doesn't scale well with wide, deep source histories? That's a failing of git I think, not the Engineers who may even have written that line when the source base was far less gnarly.

Re: A one-line change decreased our build times by 99%

#228

Post by xdavidliu » Mon, Oct 26, 2020, 2:46 PM UTC

uglycoyote wrote: post #225

pavel_lishin wrote: post #49

Earlier quoted context omitted.

> The culture change in our industry, towards warm fuzzies and away from tech screens, results in calculable waste. I have not noticed, in the past decade, any move away from tech screens whatsoever.

Are we talking about technological screens, like LCD screens here?

I believe they mean screens in the sense of technical interviews to assess candidates' technical ability.

Re: A one-line change decreased our build times by 99%

#229

Post by corpMaverick » Mon, Oct 26, 2020, 2:58 PM UTC

unishark wrote: post #102

phist_mcgee wrote: post #51

Earlier quoted context omitted.

1. You seem to be projecting a lot of your own thoughts and biases onto this article, and this discussion. 2. RTFM made sense when you wrote code in one terminal window and compiled it in another and then shipped a CD. There is no way you can RTFM for every tool you use at a modern software company. NO ifs ands or buts, it just is not happening. It sounds like you are looking at a nostalgic view of the past, and not…

I personally do think there is a systemic problem in companies trying to hire the bare minimum in skills/experience for technical roles and ending up with people operating right at the limit of their abilities (and intermittently being in over their heads). But do I agree RTFM is frustrating advice for a lot of things. Especially if you aren't going to use such information often enough, so will keep forgetting it any…

> But do I agree RTFM is frustrating advice for a lot of things. Especially if you aren't going to use such information often enough, so will keep forgetting it anyway and have to start over with the manual each time.

This is related to one of biggest frustrations in the last ten years. We used to master the tool set. But now there are so many tools. Some of them we don't used them often enough. I find myself doing a lot of guessing whereas before I knew what was going on at every step.

Re: A one-line change decreased our build times by 99%

#230

Post by scsilver » Mon, Oct 26, 2020, 3:14 PM UTC

mehrdadn wrote: post #77

nemothekid wrote: post #69

Earlier quoted context omitted.

I'm not sure this is complacency - this just seems like regular old tech debt. The build takes 40 minutes but everyone has other things to do and there is no time to tend to the debt. Then one day someone has some cycles and discovers a one line change fixes the underlying issue. I'm sure many engineering projects have similar improvements that just get a ticket/issue opened and never revisited due to the mountain of…

IMHO (from having addressed such CI issues personally on teams that otherwise wouldn't bother) it's likely due to other factors, like a lack of interest, being scared of breaking the build, not being terribly comfortable touching build scripts, or the inability to run scripts locally, than a genuine lack of time. The returns you can get can be ridiculously huge across the entire team compared to the hours you might s…

I can totally see a situation where the engineers whp made the script are long gone, the new engineers are justifying their hiring by churning out features and trying not to break things, especially things they dont own and effect everyone, like ci/cd, and that annoying but manageable 40 minute wait, just gets put on the backlog, waiting for half a year until someone with just enough experience and frustration makes a push to management to dedicate a bit of time to diving into the issue.