As I hoped in my last post, I’ve set up Gitea Actions on my homelab, with a view to completely replacing Drone which I’ve found to be pretty buggy and missing some core features¹. The process was reasonably smooth, but not entirely turnkey, so I’ve laid out the steps I took in the hopes that they’ll help someone else.

I’m using the Helm Chart to manage my Gitea installation - if you want to install Action Runners separately, there’s a good guide here.

Step-by-step instructions

Upgrade

First and foremost - Gitea Actions was introduced in Gitea 1.19, but in practice I found that some of the feature of the Helm Chart required at least 1.24.0². You’ll also need your Helm Chart to be on at least 10.6.0 - read the upgrading guide carefully, I nearly borked my whole installation by jumping versions too quickly. Here’s my upgrade.

(Potentially) Patch the Helm Chart for persistence

Depending on how you provide PVs to your Pods, this might not affect you, but I and some others found a bug whereby the (hard-coded) PV size for the Runners was too small to be provided by the provisioner (honestly didn’t even know that was a constraint that existed!). This gave me a great opportunity to learn how to use a locally-developed Helm Chart (rather than a published one) as a dependency for your own, and it was super-easy, barely an inconvenience:

• Clone the chart
• Make whatever alterations you want (e.g.)
• If the chart has dependencies (as Gitea’s does), run helm dependency update
• Run helm package . from the root of the repo - this will create a file named <name>-<version>.tgz, where those variables are taken from the Chart.yaml
• Move that archive into charts/ in your own chart’s directory - so long as the version number matches the desired-version specified in your own Chart.yaml, it will be picked up over a remote version.

Adapt your workflow to the absence of Node

At this point, you should be able to run a workflow (don’t forget that you need to enable repository actions on a repo-by-repo basis), but you might notice that actions/checkout fails with 'node' not found in $PATH, even when following the Quickstart example. Some lengthy investigation here highlights differences between Gitea Actions Runners and GitHub Actions Runners - TL;DR, you need to:

• Update runner.labels in the gitea-act-runner-config ConfigMap to include "ubuntu-latest:docker://gitea/runner-images:ubuntu-latest" (as here)
• Install Node before using the actions/checkout action, as here.

If you’re going to use Gitea Actions a lot, it’s probably sensible for you to create your own base image with Node preinstalled.

Plumbthrough Docker Socket

If you’re going to be using Actions to build a Docker image, you’ll need to make the Docker socket available to the Docker-in-Docker containers that run within the act_runner. This comment by @javiertury was very helpful, especially once I realized that setting DOCKER_HOST on the runner-pod is not the same thing as setting it on the containers that run within that pod - you can see the full configuration I needed here.

An alternative approach using the kubernetes driver is detailed here. I haven’t tried it - I do like the idea of jobs being standalone Pods, with all the control that k8s can offer (with annotations, operators, etc.), but I didn’t fancy having to provide a kubeconfig and specify driver: kubernetes on every build step. I suppose it would be possible to abstract away that configuration by creating my own build-action - the solution to every problem…

Although, on second thoughts - if only docker-builds run as separate pods, not every job/step in a workflow, then that a) leads to some inconsistency, and b) limits the value of the k8s-magic that can be injected. Maybe it’s less attractive than I thought.

Inject secrets

In order to push to the Gitea Docker Registry, or to auto-update a Deployment Repo, the workflow needs to authenticate to Gitea with a PAT. By this point in the night I was getting pretty tired and impatient, so I took the simple route of creating a secret in the repo containing the PAT; but it should be possible to use the vault-action (remember, Gitea Actions is compatible with published actions for GitHub Actions!) to retrieve a secret, once Vault’s been set up to accept OIDC auth. Actually generating such a secret might be tricky - I know there’s a plugin to provide ephemeral finely-scoped GitHub Tokens from Vault, but I doubt it would be directly installable on Gitea.

I’ve still yet to plumb in the Telegram token I used to send myself a confirmation message after publication - good opportunity for the Vault-based approach.

Update to more modern infrastructure management

This isn’t something that you need to do, but rather something that I had the opportunity to do and that I want to brag about.

I’d previously been managing the infrastructure of this blog³ with a Helm chart, as that was the only way I could figure out to extract some configuration from a definition so that it could be easily updated. Since I’ve discovered kustomize in the intervening time, no reason not to use it, in a repo that conforms to normal naming conventions. I also took this opportunity to move the Argo App Definition from a repetitive declaration in a long YAML file to a concise invocation of an extracted template.

Next Steps

(Again - this is for me, not you!)

• I might extract the “build, push, and update the deployment repo” logic to a standalone workflow. I’ve already done this at work, and it was very helpful there. I have fewer use-cases and parameters to support for my own use!
• As detailed above, reimplementing a Telegram notification when this publishes would be neat, as would the post to Mastodon step.
• And injecting secrets via Vault
• I don’t have any plans to add a call to Argo to sync the app after updating the Deployment Repo - Auto-Sync has always been good enough for me.

A much larger-scale change (which might end up obsoleting Gitea Actions altogether) would be to install CodeFresh or a similar pipeline visualization and management tool; not that that’s really relevant for the teensy single-stage “pipeline” of this blog, but I could deploy test apps with it to experiment. I’ve been out of Amazon for over two years, and I’m still aghast at how awful the accepted state-of-the-art is for Pipeline management in OSS tooling (as I previously blogged here). There doesn’t seem to be any tool that takes the view that the Pipeline is a first-class entity which manages the deployments and promotions, as opposed to deployments being the top-level concepts that are triggered by each other or by pushes to “environment branches”. The “Deployments” page for GitHub is the closest thing I’ve found to a visualization, but it doesn’t show you the actual state of the pipeline, provide any controls to it (setting/overriding deployment windows, manually rolling-back/promoting/force-passing), or provide any built-in integrations like observability.

After searching the vendor floor at KubeCon last year, CodeFresh was the closest thing I could find to an actual Pipeline tool⁴ - but, as with the other (even more awesome!) technology I discovered at that con (Crossplane), I haven’t gotten a chance to actually use it at work yet.

Why Gitea Actions?

A coworker asked this question (in comparison to “why not self-hosted runners triggering from a GitHub repo?”), and honestly it was a good question that helped me understand my own motivations better. The justifications I came up with were:

• There are many reasons to self-host, but primary for me is “reducing dependence on, and power of, centralized providers”. I’m a big believer in the societal merits of many small actors collaborating via network effects, rather than many consumers using a central platform or service; although a single well-funded and -staffed provider can probably provide more features/content than the network example, it invariably comes at the cost of excessive monetization and enrichment of capital, walled gardens, privacy erosion, algorithmic behaviour influencing, and other undesirable outcomes. I don’t hold any illusions that my tiny self-hosted forge is even the barest speck of a flicker on GitHub’s radar - but leading by example, and living life authentically according to your values, are worthwhile in-and-of themselves even if they have no tangible external effects. And hey, who knows - if my example is enough to help just one other person start investigating ways to break out of the centralized tech monopoly that is ruining our lives and civilizations, I’ll consider that well worth it.
• A secondary reason I self-host is to learn how things work. This stands in contrast to making things work - that’s good as well, of course, but (so long as we’re talking about non-essential services) I’d much rather have a semi-functional homelab with a hodge-podge of applications providing one-tenth of the functionality of a professional build, than to run a single command and have it all Just Work™️ without understanding how it works. This is a personal choice, of course - in business, the opposite choice is very often the correct one⁵.
  • This realization also helped me understand my distaste for AI Dev Tools. Prima facie, a tool which simply solves the problem for you, without providing understanding to you, is distasteful; a tool that can give you an incorrect understanding is abhorrent. As soon as I consciously recognized this reaction, however, I was quickly able to talk back to it⁶ - if one approaches AI-generated outputs with an appropriate amount of trust (which should never be 100%), and an awareness for when one is within/outside the bounds of one’s own competency, it can be an accelerant to learning as well as to simple execution.

You can of course “learn things” at different levels - I could just as well have viewed the “self-hosted runners” approach as “I’m learning how to self-host runners that are triggered from GitHub”. But the former reason was convincing enough.

• CI/CD
• Gitea
• Homelab
• K8s
• Meta