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

181–190 of 301 posts

Re: We built the fastest CI and it failed

#181

Post by maccard »

ilyt wrote: post #147
reactordev wrote: post #56

This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satellite users were already seeing the benefit from 95% of Earthly CI . I’m a huge fan of open source, however, if your business model includes an open source model - you need a differentiator. Beyond blazingly fast(tm). You need a reason for people to offer up th…

From my experience hosting our own instance of Gitlab + few CI/CD workers was few weeks of initial work (integrating with company's LDAP etc.) then around one ops-week per year worth of maintenance over last few years (50+ developers, dozens and dozens of projects). Before that we had just "a git server + jenkins + some slaves" that took even less maintenance (althought I'd imagine more fumbling on dev side with job…

We use buildkite but if I was starting fresh now I would just use github with github actions.

Re: We built the fastest CI and it failed

#183

Post by datadrivenangel »

WorldMaker wrote: post #138
shandor wrote: post #124

Earlier quoted context omitted.

Hah, thanks for that mental image. As I said the positivive sentiments I heard came from developers, and TFA is about CI (rather than boards etc. that JIRA handles, so is there maybe anything remotely positive in how AzDO implements CI, git integration, testing, etc? Or is it just rotten to the core? Hard to imagine someone would hate it more than Bitbucket Pipelines or, god forbid, Bamboo. Buuut I’m more than open-m…

AzDO Pipelines was directly the first draft of what became GitHub Actions, so technically it does have a lot to recommend it, especially if you learn the Multi-Stage YAML approach which does sort of directly feed into GitHub Actions for the eventual day you decide to migrate.

Yeah, the Pipelines are okay all things considered.

Re: We built the fastest CI and it failed

#184

Post by pxc »

verdverm wrote: post #169
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…

CI/CD & provisioning are inherently order driven tasks, I actually prefer the SDKs over the CUE implementation. The main issue with the old CUE implementation is that they had to try and align BuildKits DAG solver with CUE's DAG solver, and they worked in opposite ways. I tried to help them through this about 3 years ago (being a CUE expert). I definitely think the SDKs is a much better solution for them. Whether we…

I'm not totally opposed to powerful (Turing-complete) languages being used for configuration or defining builds— I think Nix works really well in that space, and someday Nickel may as well.

But wherever I've seen build tools from a language ecosystem that just embed a DSL in the host language (e.g.: sbt, Gradle), I've also seen projects get way too clever with their builds and create total nightmares for downstream packaging efforts. I anticipate similar problems for other kinds of configuration tools based on general-purpose languages, like CI or cloud IaC.

> Side note, I will be exploring a new CUE + Dagger setup, though it will work differently than the old Dagger engine

Sounds cool! I'll keep an eye out for it. :)

Re: We built the fastest CI and it failed

#186

Post by dpeckett »

hnlmorg wrote: post #180
dpeckett wrote: post #86

Earlier quoted context omitted.

I'm not sure feature withholding has traditionally worked out well in the developer space. The churn rate for tooling is so high that if Earthly were to intentionally cripple their product I'm sure the majority of developers would just move on to other inferior, but free, options (eg. taskfile). Maybe those that remain could be converted successfully but it's quite a gamble. A great turn around story in recent times…

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

Re: We built the fastest CI and it failed

#187

Post by psYchotic »

gabereiser wrote: post #117
AaronM wrote: post #107

Earlier quoted context omitted.

Did you mean argowf instead of argocd? Argocd is pretty simple and only syncs k8 resources.

I mean that node (not js) dashboard to build pipelines and make things look logical instead of writing 4 lines of bash. I'm not a fan of anything that adds complexity. ArgoCD/WF/ALL ARGO... is just a pretty dashboard over cli tooling. ./deploy.sh @ This is the contract you should focus on. Whatever you need to make ./deploy.sh do this, do it.

Isn't ArgoCD more of a GitOps tool? The pretty UI is mostly secondary to its main purpose for me, which is to keep the declarative "truth" in source control, and have ArgoCD be the control loop that keeps the cluster in sync with that truth. Accidentally nuked namespace? No worries, ArgoCD's (or whatever alternative, like flux) got your back!

Re: We built the fastest CI and it failed

#188

Post by angio »

mrweasel wrote: post #24
hardwaregeek wrote: post #21

At least for me, whenever I have to set up CI or touch CI, it's incredibly painful. I usually end up having to push a bunch of commits to debug stuff, and there's a lot of configuration hell. I don't know if Earthly solves this, perhaps it does. But if I were considering moving onto a new CI, I'd immediately think about having to redo this painful process. And that's at the team level. At the org level, switching CI…

CI systems are important to me, but my requirement is pretty much: Can it run a bash script. Every CI I've ever used has degraded into a bash script runner. It starts out well enough, you try to use all the build in features but at some point you fallback to running a shells script and then slowly more and more move to the script, because it's easier. Someone should just build a bash CI, something that can manage sec…

Buildkite encourages that, even plugins are just a bunch of bash scripts that are sourced at specific steps of the build.

Re: We built the fastest CI and it failed

#189

Post by dpeckett »

sanderjd wrote: post #170
reactordev wrote: post #56

This is a good write up of why you shouldn’t give away the house when you open source things. The issue was really this: Earthly being open-source, Earthy Satellite users were already seeing the benefit from 95% of Earthly CI . I’m a huge fan of open source, however, if your business model includes an open source model - you need a differentiator. Beyond blazingly fast(tm). You need a reason for people to offer up th…

I know this is controversial, but I wish commercial "source available" were the more mainstream / not-shat-upon approach to services, rather than "open core". I find it very frustrating to not be able to read the code or contribute bug fixes or self-host anything outside the "open core", and I have no need for any of the things that distinguish "open source" licenses from "source available" ones.

Stallman was right. I think it's inevitable we'll see the next generation of developer focused tooling go in the direction of AGPL or source available (eg. BSL). Ironically enough Earthly started off as BSL.
Post reply on HN