nixos/gitea-actions-runner: init

[mweinelt]

Description of changes

Module to set up gitea-action-runner instances.

https://blog.gitea.io/2023/03/hacking-on-gitea-actions/

Tested against Forgejo 1.19.1 using the token option. The runner by default wants to connect to a docker instance, but I was able to substitute that with the compatible podman socket.

Untested, but assumed maybe working:

• tokenFile option
• Multiple runners
• Docker

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[Kranzes]

Is it possible to make a NixOS VM test for this?

[mweinelt]

If you know how to programmatically retrieve a runner registration token from a gitea instance. Not keen on mocking the gitea API.

[Kranzes]

If you know how to programmatically retrieve a runner registration token from a gitea instance. Not keen on mocking the gitea API.

go-gitea/gitea#23762

I guess we could start by running a test that checks runner registration. A test that actually tries to build something might be more difficult as that requires networking and other weird stuff...

[Kranzes]

Apparently using docker/podman is optional.

[mweinelt]

If you know how to programmatically retrieve a runner registration token from a gitea instance. Not keen on mocking the gitea API.

go-gitea/gitea#23762

I guess we could start by running a test that checks runner registration. A test that actually tries to build something might be more difficult as that requires networking and other weird stuff...

Only in 1.20, didn't get backported into 1.19.

[mweinelt]

Have a draft for the test in the linked PR, that we can look into, once 1.20 is out.

[emilylange]

Looks good at first glance :)

I thought about suggesting lib.optional instead of lib.optionals, but honestly, lib.optionals looks just way better :^)

Unfortunately, I don't think I'll be able to dedicate any time to do proper in-depth tests over the next few days, as I am busy with a lot of other stuff.

But I also don't want to block this PR, so eeehhh go ahead I guess?

[Kranzes]

So when someone has docker/podman enabled in their system config this module will act differently than if they have them disabled, what if someone has docker/podman enabled but doesn't actually want to use it with gitea runner and instead use native runner? Right now what will happen is that gitea runner will be configured slightly differently and the systemd service will have to wait for docker/podman.

[emilylange]

Had a first proper look.
This is what I got so far.

Will try to test more later today or this week :)

[mweinelt]

Updating the labels against the gitea/forgejo instance requires getting a new registration token and dropping the runner config.

Guess we need to account for that.

[emilylange]

Not sure how we should compare the labels and re-register based on that, as it involves state.

The .runner contains the labels from registration-time, but I feel like there is a high probability the format of it will change in the future:

$ jq .labels /var/lib/gitea-runner/test/.runner
[
  "ubuntu-latest:docker://node:16-bullseye",
  "ubuntu-22.04:docker://node:16-bullseye",
  "ubuntu-20.04:docker://node:16-bullseye",
  "ubuntu-18.04:docker://node:16-buster"
]

---

Additionally, there are custom labels, that can be configured in the runner registration page.
They are a bit weird, IMHO.
https://blog.gitea.io/2023/03/hacking-on-gitea-actions/#what-is-the-difference-between-agent-labels-and-custom-labels-for-a-runner
Just mentioning for reference and not because we should do anything to handle them.

[mweinelt]

Also accounting for label changes now, in which case I purge the existing registration to make the runner fail, as a new token needs to be inserted, to apply the labels.

Lastly we should probably talk about the proper runtime environments, that users will want to have, so that actions like checkout, cachix/install-nix-action, etc. will work.

One idea was to provide an image based on https://github.com/nix-community/docker-nixpkgs, that includes e.g. bash and nodejs. Really wondering how feasible that is. There is an open issue for arm64 support, as currently all provided images are x86_64-only.

[mweinelt]

I think I covered all remaining issues for now.

[emilylange]

Did a final test run of the current version.
Works great :)

Except native:host 😅

Not blocking.

[emilylange]

Just a comment/pointer for other reviewers:

An example where FHS is hardcoded is
https://gitea.com/gitea/act/src/commit/a18648ee7359dbff7a8d3f022270874b840039fa/pkg/runner/run_context.go#L306

The original act repo on GitHub, on the other hand, does not hardcode it :'(
https://github.com/nektos/act/blob/aa212773804561eaee04c3b4a7d9399dfbb9cad1/pkg/runner/run_context.go#L273