NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Recently, I mentioned how I refactored the script that kept my GitHub profile up-to-date. Since Geecon Prague, I’m also a happy owner of a Raspberry Pi:
Though the current setup works flawlessly – and is free, I wanted to experiment with self-hosted runners. Here are my findings.
Context
GitHub offers a large free usage of GitHub Actions:
GitHub Actions usage is free for standard GitHub-hosted runners in public repositories, and for self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage for use with GitHub-hosted runners, depending on the account’s plan. Any usage beyond the included amounts is controlled by spending limits.
— About billing for GitHub Actions
Yet, the policy can easily change tomorrow. Free tier policies show a regular trend of shrinking down when:
A large enough share of users use the product, lock in
Shareholders want more revenue
A new finance manager decides to cut costs
The global economy shrinks down
A combination of the above
Forewarned is forearmed. I like to try options before I need to choose one. Case in point: what if I need to migrate?
The theory
GitHub Actions comprise two components:
The GitHub Actions infrastructure itself.
It hosts the scheduler of jobs.
Runners, which do run the jobs
By default, jobs run on GitHub’s runners. However, it’s possible to configure one’s job to run on other runners, whether on-premise or in the Cloud: these are called self-hosted runners.
The documentation regarding how to create self-hosted runners gives all the necessary information to build one, so I won’t paraphrase it.
I noticed two non-trivial issues, though. First, if you have jobs in different repositories, you need to set up a job for each repository. Runner groups are only available for organization repositories. Since most of my repos depend on my regular account, I can’t use groups. Hence, you must duplicate each repository’s package on the runner’s Pi.
In addition, there’s no dedicated package: you must untar an archive. This means there’s no way to upgrade the runner version easily.
That being said, I expected the migration to be one line long:
jobs:
update:
#runs-on: ubuntu-latest
runs-on: self-hosted
It’s a bit more involved, though. Let’s detail what steps I had to undertake in my repo to make the job work.
The practice
GitHub Actions depend on Docker being installed on the runner. Because of this, I thought jobs ran in a dedicated image: it’s plain wrong. Whatever you script in your job happens on the running system. Case in point, the initial script installed Python and Poetry.
jobs:
update:
runs-on: ubuntu-latest
steps:
– name: Set up Python 3.x
uses: actions/setup-python@v5
with:
python-version: 3.12
– name: Set up Poetry
uses: abatilo/actions-poetry@v2
with:
poetry-version: 1.7.1
In the context of a temporary container created during each run, it makes sense; in the context of a stable, long-running system, it doesn’t.
Raspbian, the Raspberry default operating system, already has Python 3.11 installed. Hence, I had to downgrade the version configured in Poetry. It’s no big deal because I don’t use any specific Python 3.12 feature.
[tool.poetry.dependencies] python = “^3.11”Raspbian forbids the installation of any Python dependency in the primary environment, which is a very sane default. To install Poetry, I used the regular APT package manager:
sudo apt-get install python-poetry
The next was to handle secrets. On GitHub, you set the secrets on the GUI and reference them in your scripts via environment variables:
jobs:
update:
runs-on: ubuntu-latest
steps:
– name: Update README
run: poetry run python src/main.py –live
env:
BLOG_REPO_TOKEN: ${{ secrets.BLOG_REPO_TOKEN }}
YOUTUBE_API_KEY: ${{ secrets.YOUTUBE_API_KEY }}
It allows segregating individual steps so that a step has access to only the environmental variables it needs. For self-hosted runners, you set environment variables in an existing .env file inside the folder.
jobs:
update:
runs-on: ubuntu-latest
steps:
– name: Update README
run: poetry run python src/main.py –live
If you want more secure setups, you’re on your own.
Finally, the architecture is a pull-based model. The runner constantly checks if a job is scheduled. To make the runner a service, we need to use out-of-the-box scripts inside the runner folder:
sudo ./svc.sh install
sudo ./svc.sh start
The script uses systemd underneath.
Conclusion
Migrating from a GitHub runner to a self-hosted runner is not a big deal but requires changing some bits and pieces.
Most importantly, you need to understand the script runs on the machine.
This means you need to automate the provisioning of a new machine in the case of crashes.
I’m considering the benefits of running the runner inside a container on the Pi to roll back to my previous steps.
I’d be happy to hear if you found and used such a solution. In any case, I’m not migrating any more jobs to self-hosted for now.
To go further:
About billing for GitHub Actions
About self-hosted runners
Configuring the self-hosted runner application as a service
Originally published at A Java Geek on March 10th 2024
The post Using my new Raspberry Pi to run an existing GitHub Action appeared first on foojay.