Live data from Hacker News

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

medium.com

241–250 of 256 posts

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

#241
post #162

Earlier quoted context omitted.

If Google wants my information to improve my experience, I'd love to be able to vote search results up or down. Or entire sites, like pinterest and content farms.

Wasn't that a thing? I remember a +1 button somewhere on Google Search Edit: I misremembered, it was a social network thing from Google+ https://www.techspot.com/news/43064-google-adds-1-button-to-...

There was a thing called SearchWiki where you could adjust your own results. It didn't last long.

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

#242
post #117

This 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"

They also created/maintain the kotlin linter, "ktlint".

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

#243
post #65
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…

> are we this forgiving of Equifax when they oopsie our data? The kind of culture you're in favor for, blaming engineer for mistakes and punishing them, is exactly what makes the kinda of Equifax mistake possible. Suddenly, people stop to improve things and just do the minimum possible so they can keep their job, since anything else can cause a mistake that will cost your next performance cycle (or even worse, your j…

I'm talking about blaming and punishing management, not engineers. I'm sorry that wasn't clear.

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

#244

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

Looks like its implied from the documentation

    Implies --single-branch
https://git-scm.com/docs/git-clone#Documentation/git-clone.t...

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

#245

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

Looks like its implied from the documentation Implies --single-branch https://git-scm.com/docs/git-clone#Documentation/git-clone.t...

hmm, the --depth implies single-branch, but the +refs overrode it by making sure it had the data to match all branches because of the wildcard refspec ?

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

#246

Earlier quoted context omitted.

Paywall complaints are explicitly off-topic: https://news.ycombinator.com/item?id=10178989 . I am not a moderator, but I think I've made it clear that I personally consider comments like the one I responded to be as well. FWIW, in the all years I have been on this site, I have seen this happen regularly and I have yet to see any reduction in such links or these kinds of discussions. Seeing as you've been here longer,…

We heard your complaint but you are being acting entitled now. People are free to register, free to comment, if you don't like it, downvote it. It is the top comment, that means it is being upvoted. get over it.

I tend to downvote very rarely and only for clear violations for the rules, not for comments I don't like. Telling the author why you didn't like something they did often gets them to change or explain their behavior. Just because something is upvoted doesn't mean it is something that should be on Hacker News.

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

#247
post #37

Earlier 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…

I remember hearing facebook was on the order of hours (6+) to build.

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

#248
post #178
post #173

Earlier 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…

Check out https://reflect.run/ as a replacement for Cypress. I started using it recently to do E2E testing at work in our staging environment to run a suite of tests before we move anything to production.

So far it's been great and has saved a couple of releases in a month or so of use!

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

#249

He 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…

> He 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.

It probably means including all commits.

It looks like they were successfully only pulling the last 50 commits, but they were doing that for each of 2500 branches. Now they are pulling only the most recent 50 commits for one branch.

Post reply on HN