GitHub/GitLab Action/Pipeline Runners

[hnez]

This allows registering the TAC itself as a GitHub/GitLab runner. Once registered the TAC can be used to flash artifacts onto a DUT and execute tests.

Having this feature makes the TAC a lot more useful (in my opinion) but one has to keep in mind that using it makes the TAC effectively a backdoor into your infrastructure for whoever runs you GitHub/GitLab infrastructure. I have some ideas on how to mitigate this a bit (run the runner services in network namespaces and as normal users with adequate permissions and firewalling), but these are not implemented in this PR.

Handle with care

TODO

• [x] Add service files (disabled by default) to start the runners.
  • [x] GitHub Runner
  • [x] GitLab Runner
• [x] Play around a bit more with the runners.
• [x] Investigate the build time and image size impact of this PR. The go binaries feel a bit heavy.
  • The build time increase of the Go binaries is not that bad, as we already have a Go toolchain for e.g. podman.
  • The build time increase for the target nodejs is a bit annoying though
  • The size of the RAUC bundle increased from 229M to 268M (39M or 17% larger than before). Not great, but for the feature well worth it, I guess.

[hnez]

Assigned myself because I need to take a second look at the go packaging situation.

[hnez]

Apart from requiring do_compile[network] = "1" the recipes are in a good shape now, I think. And having that in go recipes seems to be common enough that even meta-oe does it.

Here are two test runs …

• … one on github.com
• … and one on gitlab.com

I've quickly de-registered the runners again though, because of the security implications.

[jluebbe]

GitHub seems to expect that the runner can update itself: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

I've seen that outdated runners are rejected relatively soon (weeks), so I'm not sure how useful it is to ship the runner in the image. What do you think?

[hnez]

Hi @jluebbe,

I've had a look at the github-act-runner commit history and to me it does not look like they are playing a constant game of cat and mouse against the GitHub API. They have a CI job that tests against regression which does not seem to have caught a regression since its introduction six months ago.

I don't think we should advertise too much with the GitHub action runner feature, because it could stop working at any time, as you have said. It uses an unofficial client, that could just stop being developed and I have only tested a small portion of its features (for example job..container will most likely not work because we do not have a docker daemon running). But I would like to experiment with GitHub/GitLab runners and that's a lot easier when they are part of the images we publish, so I do not have to build my own.