I've standardized on getting github actions to create/pull a docker image and run build/test inside that. So if something goes wrong I have a decent live debug environment that's very similar to what github actions is running. For what it's worth.

▲

steeleduncan 6 hours ago | parent | next [-]

I do the same with Nix as it works for macOS builds as well

It has the massive benefit of solving the lock-in problem. Your workflow is generally very short so it is easy to move to an alternative CI if (for example) Github were to jack up their prices for self hosted runners...

That said, when using it in this way I personally love Github actions

▲

0x457 2 hours ago | parent | next [-]

Nix is so nice that you can put almost your entire workflow into a check or package. Like your code-coverage report step(s) become a package that you build (I'm not brave enough to do this)

I run my own jenkins for personal stuff on top of nixos, all jobs run inside devenv shell, devenv handles whatever background services required (i.e. database), /nix/store is shared between workers + attic cache in local network.

Oh, and there is also nixosModule that is tested in the VM that also smoke tests the service.

First build might take some time, but all future jobs run fast. The same can be done on GHA, but on github-hosted runners you can't get shared /nix/store.

▲

dfee 26 minutes ago | parent | prev | next [-]

same here. though, i think bazel is better for DAGs. i wish i could use it for my personal project (in conjunction with, and bootstrapped with nix), but that's a pretty serious tooling investment that I just feel is just going to be a rabbit hole.

▲

maliker 6 hours ago | parent | prev | next [-]

I'm scared by all these references to nix in the replies here. Sounds like I'm going to have learn nix. Sounds hard.

	▲	steeleduncan 5 hours ago \| parent [-]
		Gemini/ChatGPT help (a lot) when getting going. They make up for the poor documentation

▲

wredcoll 5 hours ago | parent | prev [-]

Whata the killer benefit of nix over, like, a docker file or a package.lock or whatever?

	▲	steeleduncan 5 hours ago \| parent [-]
		package.lock is JSON only, Nix is for the entire system, similar to a Dockerfile Nix specifies dependencies declaritively, and more precisely, than Docker (does by default), so the resulting environment is reproducibly the same. It caches really well and doubles as a package manager. Despite the initial learning curve, I now personally prefer Nix's declarative style to a Dockerfile

▲

themafia 3 hours ago | parent | prev | next [-]

I just use the fact that any action run can trigger a webhook.

The action does nothing other than trigger the hook.

Then my server catches the hook and can do whatever I want.

	▲	maliker 3 hours ago \| parent \| next [-]
		I wish I had the courage to run my own CI server. But yes, I think your approach is the best for serious teams that can manage more infrastructure.
	▲	robflynn 2 hours ago \| parent \| prev [-]
		I am embarrassed that I didn't think to do this. Thank you :)

▲

Storment33 7 hours ago | parent | prev | next [-]

I was doing something similar when moving from Earthly. But I have since moved to Nix to manage the environment. It is a lot better of a developer experience and faster! I would checkout an environment manager like Nix/Mise etc so you can have the same tools etc locally and on CI.

▲

tracker1 6 hours ago | parent | prev | next [-]

I tend to have most of my workflows setup as scripts that can run locally in a _scripts diorectory, I've also started to lean on Deno if I need anything more complex than I'm comfortable with in bash (even bash in windows) or powershell, since it executes .ts directly and can refer directly to modules/repos without a separate install step.

This may also leverage docker (compose) to build/run different services depending on the stage of action. Sometimes also creating "builder" containers that will have a mount point for src and output to build and output the project in different OSes, etc. Docker + QEMU allows for some nice cross-compile options.

The less I rely on Github Actions environment the happier I am... the main points of use are checkout, deno runtime, release please and uploading assets in a release.

It sucks that the process is less connected and slow, but ensuring as much as reasonable can run locally goes a very long way.

▲

woodruffw 7 hours ago | parent | prev | next [-]

Yeah, images seem to work very well as an abstraction layer for most CI/CD users. It's kind of unfortunate that they don't (can't) fully generalize across Windows and macOS runners as well, though, since in practice that's where a lot of people start to get snagged by needing to do things in GitHub Actions versus using GitHub Actions as an execution layer.

▲

moduspol 6 hours ago | parent | prev | next [-]

Me, too, though getting the trusted publisher NPM settings working didn't help with this. But it does help with most other CI issues.

	▲	tracker1 6 hours ago \| parent [-]
		Most of the npm modules I've built are fortunately pretty much just feature complete... I haven't had to deal with that in a while... I do have plans to create a couple libraries in the near future so will have to work through the pain(s)... also wanting to publish to jsr for it.

▲

globular-toast 4 hours ago | parent | prev [-]

So you've implemented GitLab CI in GitHub... We used to do this in Jenkins like 7 years ago.