Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We built the fastest CI and it failed

earthly.dev

Post reply on HN
Print view View original

261–270 of 301 posts

Re: We built the fastest CI and it failed

#261

Post by lelanthran »

smaudet wrote: post #225
BoorishBears wrote: post #219

Earlier quoted context omitted.

It sounds like you're unaware of why SSO is considered a security feature at all them, but it's covered right on the site: https://sso.tax/ It's to allow centralized access management. Stuff like firing someone and revoking their access from one platform instantly, instead running around and changing permissions in every tool manually. Or ensuring people in department A can't be invited to some platform for people in…

> It sounds like you're unaware of why SSO is considered a security feature Technically it's an anti feature... The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company). At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridic…

> At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag).

Can you explain more about how this works for SSO?

Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said?

I looked into SSO services and they're bloody expensive, so if I can cheaply do it myself, I will.

Re: We built the fastest CI and it failed

#262

Post by otabdeveloper4 »

cyberpunk wrote: post #146
bluGill wrote: post #28

Earlier quoted context omitted.

Why should senior devs know that? Someone needs to know those differences, but on a large enterprise project you have a team that keeps the CI system working. The rest need to know how to checkin a file and how to check the CI output. They shouldn't care about those details. I expect any senior developer CAN learn the above things. However that doesn't mean they are worth knowing.

Just to be clear, your question is: why should a senior developer -- whose job ultimately involves managing a complex set of text files -- understand basic concepts behind the industry standard tooling for managing ... text files? Complete waste of time, they should be out playing golf with a board member instead, right..

> they should be out playing golf with a board member instead

As a senior developer myself, I approve this message!

Re: We built the fastest CI and it failed

#263

Post by geggo98 »

shykes wrote: post #252
pxc wrote: post #154

I looked briefly at Earthly a while ago for work because I have to write CI integrations for a whole bunch of CI platforms (GitLab, Azure DevOps, Jenkins, and maybe GitHub Actions). I ended up going with a very similar product (i.e., another nice BuildKit frontend with integrations into a bunch of CI systems), Dagger, because the DSL it used for defining pipelines at the time seemed better to me. I ended up deeply re…

> Dagger devs have de facto abandoned that language entirely in favor of churning out SDKs for the most popular programming languages— all imperative, all Turing-complete, and all, imo, bad fits for the space. Disclaimer: I’m the CEO of Dagger. You’re right that we offer SDKs for popular languages, which happen to be imperative. But Dagger remains a declarative system, so what you liked about the earlier versions is…

While you are here: the Node.js syntax highlights on you QuickStart docs seems to be broken. Tested with Safari and Chrome on a recent macOS. That’s not a huge issue, but makes it a bit harder to grasp what’s going on and how the Dagger SDK actually works.

Re: We built the fastest CI and it failed

#264

Post by hnlmorg »

edgyquant wrote: post #229
hnlmorg wrote: post #180

Earlier quoted context omitted.

> I'm not sure feature withholding has traditionally worked out well in the developer space. It’s worked well for GitHub, Slack, and pretty much every service that only offer SSO behind enterprise subscriptions. The trick is to offer enough to make people productive but not so much that there isn’t a worthwhile upgrade path.

Neither GitHub nor slack are open source

Both GitHub and Slack have free tiers. Same principle, different software license.

Re: We built the fastest CI and it failed

#265

Post by hnlmorg »

dpeckett wrote: post #186
hnlmorg wrote: post #180

Earlier quoted context omitted.

> I'm not sure feature withholding has traditionally worked out well in the developer space. It’s worked well for GitHub, Slack, and pretty much every service that only offer SSO behind enterprise subscriptions. The trick is to offer enough to make people productive but not so much that there isn’t a worthwhile upgrade path.

True (for web apps and multiuser applications). Earthly is a single binary CLI on top of Docker buildkit so it's a bit trickier for them.

I’m not claiming it’s easy. Just that withholding features while still offering free tiers is a tried and tested business model that has demonstrated a lot of success for a lot of companies.

Re: We built the fastest CI and it failed

#266

Post by rewmie »

shepherdjerred wrote: post #200
rewmie wrote: post #179

Earlier quoted context omitted.

> It is much harder to set up caching/parallelization with GitHub Actions, Jenkins, Docker, and Make than it is with just Earthly I never used Earthly but I have to call nonsense on this take. Caching and parallelization is a solved problem in GitLab, GitHub, CircleCI, etc. It's so trivial that it's pipelines 101. Caching and parallelization might be easier in Earthly but any improvement over "trivial" is something n…

How do you usually do caching for complex, multi-language projects in this case? How do you guarantee _only_ changed targets are rebuilt when dependencies, like a language version or external library, change? With Earthly you just... write your Earthfile. You get everything for free. Caching and parallelization _also_ works locally, so I see that speedup in development.

> How do you usually do caching for complex, multi-language projects in this case?

As a software engineer, I do my best to keep my systems as simple as possible. Each build stage either caches artifacts or delivers deployable packages, and they consume dependencies that are either built in each pipeline run or already delivered through other means.

> How do you guarantee _only_ changed targets are rebuilt when dependencies,

Why do you want that? Other than saving a few pennies here and there in pipeline runs, you do not have anything to gain. Your builds should consume dependencies already packaged and delivered, either from a OS image, your own container image, or a package deployed by you or a third party, and your build must be reproducible and tied to each and every pipeline run.

> like a language version or external library, change?

If you're mindlessly bumping up language versions and external libraries, you have more pressing problems with your setup than what's supported by the CICD system you're using.

Re: We built the fastest CI and it failed

#267

Post by verdverm »

stavros wrote: post #236
verdverm wrote: post #164

Earlier quoted context omitted.

Try Dagger, it's better than Earthly I'm a happy user, not paying them yet

In what way? Last I tried both, I could only make Earthly work (though now I'm a fan of CUE because of Dagger).

Dagger is language SDK based now, sad to see the CUE go myself, but I actually prefer this SDK way now

Re: We built the fastest CI and it failed

#268

Post by nvm0n2 »

oftenwrong wrote: post #242
nvm0n2 wrote: post #125

Earlier quoted context omitted.

A CI system like TeamCity will give you that sort of thing for free though, without needing an Earthfile. It just dedupes builds at the same commit, and keeps checkout directories between builds on the agents, so if the build tool has a cache then it's automatically reused. Works great. Given that it's hard to understand what exactly this is for? Build systems normally try to avoid redundant work for local purposes a…

One of the chief benefits of Earthly is builds that are always clean and predictable. This is especially important on a shared build server.

So they claim. And yet ultimately they do it by caching things, same as every other system.

Re: We built the fastest CI and it failed

#269

Post by jnwatson »

ianwalter wrote: post #198
jnwatson wrote: post #73

Earlier quoted context omitted.

The only part of the Earthly pitch that resonated with me was the ability to run the CI locally. When debugging your CI, it is just faster to find problems when you can run on your own box. I have a gnarly GitHub Actions script that took forever to get right because the debug cycle was 10 minutes long.

I feel you on that one. There is also Act ( https://github.com/nektos/act ) and Dagger.io.

I have a very complicated script and Act didn't work on it.

Re: We built the fastest CI and it failed

#270

Post by BoorishBears »

lelanthran wrote: post #261
smaudet wrote: post #225

Earlier quoted context omitted.

> It sounds like you're unaware of why SSO is considered a security feature Technically it's an anti feature... The "feature" you are talking about is really identity management not sign on (which, btw, users have different identites, outside of the scope of a single company). At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridic…

> At its core it's just a delete function for a username. Putting that in a script with http access should be enough (and not put behind a ridiculous price tag). Can you explain more about how this works for SSO? Let's say I'm trying to launch a product (which I am), and want to have SSO as part of the package (which I do), how do I implement what you just said? I looked into SSO services and they're bloody expensive…

Their reply is not SSO, it's some toy alternative they're proposing that none of your customers would accept (like saying "Dropbox is just rsync")

SSO is hairy enough that you can't write it from scratch in any reasonable amount of time for what a typical SaaS needs.

There's OSS SSO you can host yourself that supports enterprise : https://www.keycloak.org/

If you're B2C Firebase Auth is cheap, and doesn't actually require hosting on Firebase

Post reply on HN