Live data from Hacker News

Run GitHub Actions locally

github.com

131–137 of 137 posts

Re: Run GitHub Actions locally

#131
post #101

Earlier quoted context omitted.

I'm convinced that they specifically won't do that so that people won't use them to build competing products. Actions is one of the pieces that make GitHub money.

> Actions is one of the pieces that make GitHub money. How do you figure that? I'd buy "lock people in the platform," but in that way GitHub Issues has been the moat for far longer than Actions has

I figure because they charge for minutes, I'm not saying that it actually turns a profit. My company also pays for certain "xl" machines.

Re: Run GitHub Actions locally

#132
post #125

Earlier quoted context omitted.

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…

In addition to https://devenv.sh and https://bob.build , here are 2 others that are based on Nix. - https://flox.dev - https://www.jetify.com/devbox

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.

Re: Run GitHub Actions locally

#133
post #95

Earlier quoted context omitted.

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…

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

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.

Re: Run GitHub Actions locally

#134
post #131

Earlier quoted context omitted.

> Actions is one of the pieces that make GitHub money. How do you figure that? I'd buy "lock people in the platform," but in that way GitHub Issues has been the moat for far longer than Actions has

I figure because they charge for minutes, I'm not saying that it actually turns a profit. My company also pays for certain "xl" machines.

Almost every company I know of is in love with self hosted, or 3rd party, runners because they can't reason about OIDC auth into their cloud, or it's more evil sibling VPN

I'm open to your suggestion but I struggle to get onboard that Microsoft thinks that CI compute billing is the future

Re: Run GitHub Actions locally

#135
post #126

I've had the displeasure of working with Macs on which we wrote code that would end up being a docker container. But what is compiled on a Mac is an aarch64 container. What is compiled on an AMD64 Linux machine is amd64. This is annoying when the code you write is native or reaches out to native stuff. Then all of the sudden your container that builds perfectly on the Mac doesn't build on Linux anymore. (and vice ver…

> And their Mac runners do not come with Docker, and it cannot be installed. ????? If you have a Docker runner on macOS, you're just running a Linux runner in a VM. So just register a Linux runner in a VM, right?

Sorry for the late reply.

GitHub Actions' macOS runners do not come with Docker installed, because of licensing issues: https://github.com/actions/runner-images/issues/17

Then there is the issue that the macOS runners are virtual instances, and pass-through virtualization has not been enabled:

https://github.com/douglascamata/setup-docker-macos-action#:...

Re: Run GitHub Actions locally

#136
post #127
post #23

I think this is really cool. We're tackling this problem from the other side by building `pixi` (pixi.sh) which bundles project / package management with a task runner so that any CI should be as simple as `pixi run test` and easy to execute locally or in the cloud.

My team has a setup that sounds essentially the same using Nix via devenv.sh. We deterministically bundle and run everything from OpenTofu and all its providers to our programming languages runtimes to our pre-commit hooks this way, and it also features a task runner that builds a dependency graph and runs things in parallel and so on. Our commands for CI are all just one liners that go to wrappers than pin all our d…

I'd be interested to know more about a team that uses Nix and Guix. Is there a website or email an interested party can contact?

Re: Run GitHub Actions locally

#137
post #69

Earlier quoted context omitted.

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
Post reply on HN