Slow CI is a perk.
We built the fastest CI and it failed
221–230 of 301 posts
Re: We built the fastest CI and it failed
#222Earlier quoted context omitted.
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.
Have you ever used ArgoCD? No one EVER should run deploy.sh like how you propose it. ArgoCD abstracts away access to a k8s cluster (login through dex). It has strategies of how to deploy k8s resources like through retry, replace (which you would need to write manually in your deploy.sh). It gives you debug output for your deploy process (yes thats a thing, you do not assume every deploy just works). ArgoCD also can a…
And fuck-us-all if you go on vacation.
In a small business (read: startup), `deploy.sh` is all you should have. When you go on vacation and it breaks, I just need to read a bit of bash/python/php/whatever-script-you-use.lang and fix the broken stuff.
Re: We built the fastest CI and it failed
#223Earlier quoted context omitted.
When it was an open source project, yes. You are correct. Ever since GitLab went commercial, it's been behind a paywall. Apparently you can run runners on self-managed CE so I'm going to look into that.
I run a self-managed CE GitLab with my own runners — works as expected (no payment required).
Same, been doing this for many years and upgrade frequently.
Re: We built the fastest CI and it failed
#224I'm quite passioned about CI/CD and working in this field for the last 7 years. I'm keeping a close eye on jenkins, tekton, circleci, travis, github actions, gitlab etc. and never ever heard about earthly. Btw. one thing the person doesn't get: Everyone wants to have fast and reliable builds but no one cares. No one. CI/CD Systems in a developers eye are blackboxes. They don't care. And its already a solved problem s…
GitHub Actions is the same as everything else. It doesn't work any better or worse. But the UI is clunkier, you can do less with it than other systems, it lacked important features forever (still does). The only reason you think it's significantly better is psychological.
The "market" of actions is better than competitors because the incumbent gets an advantage, and it trades on the idea of a generic executable as a 3rd party plugin, unlike other systems that try to force you into a particular language or paradigm. But other systems do this too.
Re: We built the fastest CI and it failed
#225Earlier quoted context omitted.
Not sure what you're talking about. It's not like without SSO everyone in the company has to all use the same password. Services allow people to have separate users with separate privileges.
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 ridiculous price tag).
Separate services otherwise are enough, no need for SSO.
Re: We built the fastest CI and it failed
#226Earlier quoted context omitted.
I thought using your own runners for free in Gitlab was already an option before Github Actions even existed
When it was an open source project, yes. You are correct. Ever since GitLab went commercial, it's been behind a paywall. Apparently you can run runners on self-managed CE so I'm going to look into that.
(GitLab employee but familiar with this because I use it personally as well)
You can always connect your own runners to GitLab, whether SaaS or self-hosted, and whether free/CE or premium/ultimate/EE. GitLab SaaS also comes with free use of the central runners up to a quota. I'm not sure about the history here but as far as I know this has always been the case.
Re: We built the fastest CI and it failed
#227Not to rain on the parade here but this is literally a copy-pasta product. Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and surprise surprise when you look at where he came from...Ex-Google, Ex-VMW, RabbitMQ... If OP wasn't in and around the source of all these tools above then they were at the very least first cousins to the story. The sales cycle is long, integrations require multiple dimensions of ex…
> Not to rain on the parade here but this is literally a copy-pasta product. More to the point, the product offered no compelling reason to use it, let alone pay for it. Being "fast" is not a selling point. Developers don't want slow pipelines, but that does not mean they want fast pipelines. The speed that the pipeline works is more depending on how the pipeline is setup than the overhead of the pipeline service, an…
> Being "fast" is not a selling point
It could be, if that is a pain point for the customer. You could be 10x faster than any other option, but if "slow builds" are not on the top 10 list of problems they are dealing with, it's a meaningless statistic.
Re: We built the fastest CI and it failed
#228I'm quite passioned about CI/CD and working in this field for the last 7 years. I'm keeping a close eye on jenkins, tekton, circleci, travis, github actions, gitlab etc. and never ever heard about earthly. Btw. one thing the person doesn't get: Everyone wants to have fast and reliable builds but no one cares. No one. CI/CD Systems in a developers eye are blackboxes. They don't care. And its already a solved problem s…
That's an interesting perspective. I used to work at a large company with a massive Jenkins setup. The nice thing about Jenkins is that your unix skills translate. It basically just runs a shell script and you can do anything.
In GitHub actions, the process is super abstracted and opaque. It doesn't really match anything I've used before and knowledge of unix doesn't help top much. I can't really reason what will happen, things are the way they are because that's how GitHub actions work, rather than something I can work out.
I can see a certain part of the build is slow, I know how I'd fix it if I were on Jenkins land, but here it's just too abstracted. I end up just googling and finding someone else with the same problem and copying how they fixed it.
I do agree that gitlab is worse somehow than GitHub actions.
Re: We built the fastest CI and it failed
#229Earlier 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.
Neither GitHub nor slack are open source
Re: We built the fastest CI and it failed
#230Earlier quoted context omitted.
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.
I think there is certainly some value to that (the other posts don't appear to be fully grasping the complexity of the problem), but Earthly feels closer to an open source consultancy project than venture capital funded startup.
Yeah, I'm a little lost on how the value proposition of Earthly isn't being understood by others.
I'm guessing that many of the posters don't understand that Earthly works locally.