Every mention of Github Actions is an occasion to start looking for the best alternative in <current_month>, let's go!
Is Dagger usable yet? Is there still hope for Earthly? Are general purpose workflow systems winning any time soon, or are we still afraid of writing code? Any new systems out there that cover all the totally basic features like running locally, unlike Github Actions?
Earthly has pivoted away from their CI/CD products: they’re shutting down Satellite, and they’re stopping active maintenance of the Earthly open source project.
I think we could build something on top of nix that is as easy to use and powerful as earthly, but gets all the nice stuff from nix: reproducibility, caching, just use any command from any nix package, etc
That's mostly what we've built with Flox [1] (though I'm not exactly sure what you mean by run any command from any Nix package). It looks and feels like an amped up package manager, but uses Nix as kind of an infrastructure layer under the hood. Here's a typical workflow for an individual developer:
- cd into repo
- `flox activate` -> puts you into a subshell with your desired tools, environment variables, services, and runs any setup scripts you've defined
- You do your work
- `exit` -> you're back in your previous shell
Setting up and managing an environment is also super easy:
- cd into project directory
- `flox init` -> creates an "environment"
- `flox install python312` -> installing new packages is very simple
- `flox edit` -> add any environment variables, setup scripts, services in an editor
- `flox activate` -> get to work
The reason we call these "environments" instead of "developer environments" is that what we provide is a generalization of developer environments, so they're useful in more than just local development contexts. For example, you can use Flox to replace Homebrew by creating a "default" environment in your home directory [2]. You can also bundle an environment up into a container [3] to fit Flox into your existing deployment tools, or use Flox in CI [4].
All that stuff I described is free, but we have some enterprise features in development that won't be, and I think people are going to find those very appealing.
I built something like this out using an old version of Dagger and found it enormously complicated, and the they rewrote everything and abandoned the version of Dagger I used.
When I they did, I said "fuck it" and just started distributing a Nix flake with wrappers for all the tools I want to run in CI so that at least that part gets handled safely and is easy to run locally.
The worst and most annoying stuff to test is the CI platforms' accursed little pseudo-YAML DSLs. I still would like that piece.
devenv.sh tasks might be a good basis for building on it. I think maybe bob.build also wants to be like this
Yes! I knew that those are comparable to devenv.sh (what my team uses; love it!) in terms of environment management but wasn't yet aware of whether or not they also have task runners like one might use to build CI/CD pipeline logic.
I also want to say that this approach has largely spared my team the pain many users seem to have with Docker on aarch64 Macs. Nix works well on both aarch64 and x86_64, and doesn't require emulation to run. This is really more appropriate for running development tools locally, I think.
Gitlab? It's been around longer than Actions, it's much better and honestly not sure why anyone would consider anything else (but happy to hear if there are reasons).
In the context of this submission, one will want to exercise caution because they and their forgejo friends are using forks of nektos/act, with all the caveats of both "act" and "fork"
Seems fine to me, I don't really understand why people think CI is hard and they need to shop a different platform. All these systems are is a glorified shell script runner. It seems like developers just keep making up new DSLs over and over to do the same things.
We ended up running every job in a docker container, otherwise the Jenkins admin had to keep installing various tools on the runners. Gitlab supports this workflow natively so seemed the obvious choice.
Jenkins also supports this out of the box, and if it didn't have it for the pipeline DSL, again, Jenkins is a general purpose runner, you can just install docker, and run the script to run builds in the docker containers
I wish jenkins had a better config as code option. Not crazy about groovy and you still need to click in the UI to get some set up before you can use. Maybe im stuck with an old version or something
I mostly like Jenkins though, idk why people so desperately want to always move to something new. I guess I've never been on the maintenance side of running Jenkins for thousands of engineers though.
it's hard since you don't have the right environment, you can't debug, can't easily run locally and you have to push a change, and wait for the code to run on a remote machine 100x less powerful than you old laptop.
If these systems thought a moment about the developer experience, they'd be magical, but they do not.
It's still a miserable experience to maintain it, update it, deal with mostly old plugins, dynamically loading the tooling, groovy idiosyncrasies.. and UI/UX that despite recent efforts continues to feel terrible.
Managing the underlying infra is painful, and it remains a security liability even when not making obvious mistakes like exposing it to any open network.
And good luck if you're having that fun at a windows shop and aren't using a managed instance (or 5).
>It's still a miserable experience to maintain it...
How so? I've been maintaining an instance for a decade, and it really doesn't seem that bad. Updating plugins we do about monthly, it's largely clicking a couple buttons in the UI. Updating Jenkins itself is an apt update. Groovy takes a bit to grok, sure, LLMs help a lot here. The UX isn't that bad, IMHO, but I can see why some would say that. We've switched over almost entirely to using a couple runners, docker, and Jenkinsfiles, which works great. We do still run deploys directly on the Jenkins box, largely because we need to run them single-threaded so they don't step on each-other with load balancer rotations.
Your use case is just fine because you're barely actually using Jenkins.
I can give you a few examples of where it falls short:
- security: there are constant CVEs about anything and everything in Jenkins
- upgrade paths: if your company uses lots of plugins, the resulting spaghetti is of Italian proportions
- if said company is in a Windows-only infra, on prem, and they still decided to use Jenkins then good luck doing anything. Try putting an agent on a non-system disk for example, Windows paths aren't handled and you find yourself already passing very specific "pre" commands that your master will send over ssh.
- Said ssh connection can be lost due to a variety of things for which there are quite a few combinations of parameters when invoking Jenkins
- While we're at it, SSO isn't exactly supported in Windows environments. There are two external plugins you can try, one created because the other doesn't work, and even then good luck with that.
- At scale you end up having to be at least minimally interested in GC tuning, as Jenkins runs within the JVM
- UI: normal "Views" are not informative, and a bunch of custom views need to be made but rarely work with all sorts of plugins that people using your CI can consider crucial (say, parametrized cronjobs)
- Using the functionnalities Jenkins offers to "install tooling". Try to get it to use a certain version of node in a pipeline. Any current typical CI solution turns that into a straightforward task that's extendable, but in Jenkins you have to configure a very archaic and barely-working "tooling" area in your system to use that, and this barely works beyond the most basic tools.
- Having to maintain enterprise-level groovy libraries. Good luck. It's Groovy but not exactly Groovy. It's all inside the JVM, but inside Jenkins's abstractions of it inside of the JVM.
- Good luck monitoring lots of agents and doing typical tasks with them. Maintenance Windows are slowly coming in, monitoring sort-of-kinda-works via plugins..
I've maintainted instances in small companies and larger ones. With less custom stuff and with a lot more. Compiling C++, C#, Java/Kotlin, Objective-C/Swift. Building webapps, iOS SDKs, Android SDKs, and native Windows apps.
Jenkins can do everything if you bend it the way you want with some plugins and custom code. That's a strength that nothing else offers, but by and large it is a weakness of CI in the long run. Being opinionated isn't amazing, but sometimes it is required to be less complex, easier to maintain, more secure, easier to use, etc.
Let me throw another one out there: how about TeamCity on premise? Still can be done for free and the last time I used it (years ago) it left a very complete, stable and easy to use impression on me. Jenkins by comparison seems heavy and complicated.
Is Dagger usable yet? Is there still hope for Earthly? Are general purpose workflow systems winning any time soon, or are we still afraid of writing code? Any new systems out there that cover all the totally basic features like running locally, unlike Github Actions?