Gitea Actions, Python, and Debian
Gitea Actions - the new self-hosted CI
As of the brand new Gitea 1.19.0, Gitea finally has a built-in Actions system! It’s intentionally very close to GitHub Actions, meaning that many of the yaml files you’ve carefully built up over the years will just work out of the box! And for the most part, that’s what happens… but since this is a new system, there are always some rough spots.
In this case, the question is “what happens if you try to run the GitHub
setup-python action on a Debian runner?”
Tl;dr: it explodes in a very confusing way. Let’s dive into that.
(Want to skip to the important bits? Click here!)
I run Gitea on my local Unraid server in Docker, which has a single VM set aside to act as the runner. Actually getting the runner set up was pretty great - the full instructions are here, but here’s the basics.
On Gitea, you’ll need to start by enabling Actions. This is deceptively simple, but does require editing the
app.ini file. Just drop this anywhere in it:
Restart Gitea and you should see a new option,
Runners, in the Site Administration section.
After that, you’re good to start on building the runner, and that general process is going to look like this:
- Build and update your VM
- Install Docker CE on the runner
- Grab the precompiled binary and drop it in the home folder
I renamed the precompiled binary to
act_runner just to make the rest of the steps easy, but after registering the runner, you should be able to run it manually (
act-runner daemon) and see it pop up in the Gitea runners list!
At this point, there’s only one more thing you have to do – because this is still technically a beta feature, Actions have to be enabled on a per-repo basis. Go to the repo that you want to test with and go to Settings > Repository > Advanced Settings. Buried in the many options there, you’ll find this one for Actions – enable it and click the save button at the bottom of the section.
Now that we have all the pieces in place, we can finally test some actions! You should be able to use pretty much any GHA file (and Gitea will recognize files in both
.gitea/workflows/*.yaml), but start with a simple one. Since pretty the majority of my projects are in Python, I started with this existing release script for a Python-based system utility I wrote for myself:
You’ll notice that there’s only one change from a standard GHA file – I’ve prepended
https://github.com/ to each step that uses an external action (and I’m not even 100% sure if that’s needed, but that was in the examples so I’m rolling with it).
I also had to create a new secret – since I use the Personal Access Token on GitHub added to the repo, I went looking for a suitable replacement on Gitea. I’m very pleased to report that not only can repositories hold secrets (as expected) but you can assign secrets to your user account and they’ll automatically apply to all your repos! I created a basic token with repository permissions and added it as a user secret called
PAT – that section of the run file works 100% as expected. Bravo, Gitea!
When I went to run this with a push though, something interesting happened: it exploded on the “setting up Python” step, which I honestly expected to be fairly nondescript. What happened?
When debugging, the action failed with the following error:
Before we get too deep here, this is a partial red herring, but one that will eventually lead us to the real problem. The reason it’s a red herring is that the error message is correct, but not for an obvious reason.
Debian doesn’t ship with
lsb-release, the package that will let you run the
lsb_release command. (You can install it with
sudo apt install lsb-release, but that still won’t solve the issue.) What it’s actually saying is that it can’t find
lsb_release on the Docker container the runner downloaded. For reasons I don’t completely understand, this is not a problem that is solvable by simply installing
lsb-release in an earlier step of your workflow file – it’ll still explode with the same error.
On your runner VM, in the directory where you registered
act_runner, there is a hidden file called
.runner. If you open that up, you’ll see that there is a section called
labels, and it (most likely) looks like this:
node:16 containers work well for most things, but for some reason they don’t work out of the box for this use case. What we can do is swap out these images for ones that are configured correctly:
After you change out the label section, restart the runner and then restart the job through the Gitea interface (or a push to your repo).
In a tremendously surprising move, even the release action worked out of the box, successfully pushing a release to my repo with no issues. It created the release, but as it turns out, Gitea will not allow you to create a release that contains assets in a single call. Here’s the replacement for the release action listed above:
Not particularly glamorous, and getting this figured out was kind of a pain, but hey, it’s at least fairly portable. Besides, copying and pasting between workflow files is a time-honored tradition. 😂
Major props to the Gitea team for getting this out the door – I’m so excited that it’s here and very excited to use it on my repos!