Minimal Git CI using hooks
29 points by klingtnet
29 points by klingtnet
There are (at least two) CI problems:
make test when code changesmake test on Linux, Windows, and MacHmm interesting. I feel like the hard part of CI is the job engine — including the ability to debug it when there’s a failure. At least that’s where a lot of development happens. I’m idly building a CI system at https://ci.pico.sh mainly because I’m dissatisfied with the ergonomics of the various job engines that exist. They all treat DX and debug ability as an after thought. I also hate DSLs and think cascading yamls are slowly sucking the life force out of me
Yup, this solves the easy one, and I think you could stretch it to support the BSDs with qemu, and multiple distros with docker, but beyond that I think you want to look into something more complete.
I've done this on top of gitolite, shipping off to Temporal for infinite controllability of the build process, able to reject a push if the run fails (though I tend to favor letting the hook go and then worrying about failures elsewhere).
Great fun and simple too.
I really like the access control tools that come with gitolite, and the way you can push to a nonexistent repo to create it. Definitely a solid setup.
Another bare-bones CI, centered around running shell scripts is laminar CI. It does add some porcelain [a web UI].
I like the simplicity you've brought to your "forge". I just wanted to let you know that a simple, light, container system for your CI could be bubblewrap. It's easy to setup and run.
I also have a question: you can't reject push if CI fail with ng, I guess. How do you handle that?
I also have a helper that uses landlock to lock down scripts which (imo) is a bit simpler to use. You can of course add on podman/docker or bubblewrap if you need even more isolation.
Personally I don't like rejecting pushes due to CI failures, for the same reason I don't run a pre-commit hook that runs tests. I find that sometimes you want to push or commit work even if it's broken, and it can make pushing code very slow. However, if you want to reject pushes, you could just run the CI synchronously without nq. If exit code is not 0, the push will be rejected.
One solution could be to have non-main branches run with nq and the main branch run without it.
I find that sometimes you want to push or commit work even if it's broken
FYI --no-verify is the escape hatch in this case.
Personally I also wouldn't run it during push. If someone needs something like this a better approach would be pushing to a branch that gets merged to main on success (maybe enabled via git push options).
This was one of my first "git hacks". Many years ago, in a windows only corporate environment I used a Mac mini as a local CI server, used by the entire team, for an iOS app.
UPDATE: found it at https://mccd.space/git/. Thanks! Looks like you are using a fork of stagit?
Nice.
I was running forgejo + woodpecker up to a couple of months ago but I removed it all to pursue a much lighter setup, like yours. They are great piece of software, but I don't need most of the features.
The CI was the next puzzle piece I wanted to solve, this is a timely post!
Do you have any public projects, and if so, how do you distribute it to the public? I have a small library that I will release shortly, and was thinking of mirroring to sourcehut.