I left Github a while ago and have been relying on simple pre-push scripts in my workflow, but would like to be able to test PRs from others without putting my machine at risk. Besides codeberg and radicle (neither of which have reliable CI), I also have a build machine, where I could run CI jobs, however it is important that the CI jobs can also run locally so that external people do not require access to the build machine.
Is there a CI that can do those things (run locally and remotely)?
You may try out https://github.com/melezhik/sparky which is a local / remote task runner with nice front end and scripts could be written on many languages
@onlinepersona don’t do it. Create makefiles or whatever that runs the build as a series of Podman/Docker commands or whatever, then just put as little CI config as possible around it. You’ll thank me when you need to switch CI system.
I can’t upvote this comment enough. I grow so angry at Gitlab ci and GitHub actions. Even Jenkins got in on the junk.
Just use normal build tools and you can use whatever cruft you want around it with just a few lines instead of monster ci file that goes out of date next year.
I use forjero with forgero runners.
Basicly 100% compatible with GitHub actions and all locally run via podman.
Strong recommend. It’s all designed to work together and everything just works.
Isn’t Forgejo runner still in alpha though? How stable is it?
I can’t speak for general use. But use it to:
- Build Rust artifacts
- Rebuild static sites, upload them to a bucket, then clear the CDN cache.
It works perfectly for me and I have not run into issues. But it might be bad for other people. I just know it works well for me.
I remember seeing dagger trying to solve exactly this problem around 3 years ago, but it was still in alpha at that time. Not sure how good it is now.
Surprised to not see Gitea here, thats what I’ve been using for awhile now for my little projects
gitea has had some organizational problems so a lot of people have been using forgejo instead, which is just a community fork of gitea plus some more features
Gitlab runners can run locally
I don’t think that’s accurate, the post is from seven years ago. Additionally there are a lot of materials online that indicate your still can - https://virtualizare.net/devops/how-to-run-gitlab-runner-locally-best-practices.html
I think there is a misunderstanding, what running locally means.
You can run a gitlab runner on your local machine, but it needs to pulls it’s jobs from git. It also requires gitlab to register your runner, so it can’t really work for new contributors to use themselves.Ahh, I see what you mean.
At that point I feel like you may as well just use makefiles. Did that at an old company, it had params for local deployment testing vs CICD. This also let’s you define how you break the local deployment tests, as usually you can’t really fully test a CICD locally.
would like to be able to test PRs from others without putting my machine at risk
I know what you mean, but do you not read the diff? Are you working on codebases that are so obfuscated that you can’t spot a malicious command?
What if they pull in a new dependency with a CVE or that executes malicious code? How am I supposed to check that? Or what if I miss a bug in the justfile or shell script?
Run your CI in a sandbox.
For example gitlab allows you to run in a docker image.
Unless the attacker knows a docker CVE or is willing to waste a specter style 0-day on you, the most they can do is waste your cpu cycles.Yep. Hell, be very paranoid and run it in a container on a runner VM on your box if you like.
And you can use podman or sysbox there.
Put as much of your testing in shell scripts, or even better, Ansible playbooks, so that you can run them locally. That way your CI system just does
ansible-playbookThere’s a very good Ansible collection for podman, so you can orchestrate the unit tests to run inside a container for full isolation
