How to Run Github Action Locally on Raspberry Pi

Recently, I shared my experience of revamping the script that managed my GitHub profile updates. But that's not all - since my exciting win at GeeCON Prague, I've also become the proud owner of a Raspberry Pi. So, naturally, I decided to experiment with self-hosted runners for GitHub Actions. Here's what I discovered along the way.

GitHub Actions offers extensive free usage, but the landscape can change at any time. As a proactive measure, I wanted to explore alternatives before the need to migrate arises. This led me to delve into the world of self-hosted runners.

Self-hosted runners offer a flexible alternative to GitHub's default runners. They allow you to configure your jobs to run on your own infrastructure, whether on-premise or in the Cloud. While the documentation provides all the necessary details for setting up self-hosted runners, there were a couple of challenges I encountered during the process.

One of the key realizations I had was that GitHub Actions depend on Docker being installed on the runner. This meant that whatever script I ran in my job would execute on the running system, rather than in a dedicated image. As a result, I had to make adjustments to my initial setup, including downgrading Python to match the version installed on Raspbian, the default operating system for Raspberry Pi.

Here's the updated version of the script:

jobs:

  update:

    runs-on: ubuntu-latest

    steps:

      - name: Set up Python 3.x

        uses: actions/setup-python@v5

        with:

          python-version: 3.11

      - name: Set up Poetry

        uses: abatilo/actions-poetry@v2

        with:

          poetry-version: 1.7.1

Handling Secrets and Environment Variables

Setting up secrets and environment variables posed another challenge. While on GitHub, you set secrets via the GUI and reference them in your scripts, self-hosted runners require a different approach. Environment variables are set in an existing .env file within the folder, allowing for a more segregated setup.

Here's how you can reference environment variables in your script:

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 }}

Making the Runner a Service

Lastly, to ensure seamless operation, I needed to configure the runner as a service using built-in scripts provided by GitHub. This involved installing and starting the service using systemd.

Here are the commands to make the runner a service:

sudo ./svc.sh install

sudo ./svc.sh start

Conclusion

While migrating to a self-hosted runner presented some challenges, it was a valuable learning experience. Understanding that the script runs on the machine itself was a crucial insight, prompting me to explore options for automating the provisioning of new machines in case of crashes. For now, I've decided to hold off on migrating more jobs to self-hosted runners, but I'm open to exploring containerized solutions in the future. If you've come across any such solutions or have any insights to share, I'd love to hear from you. In the meantime, I'll continue to tinker and experiment with GitHub Actions on my Raspberry Pi.