Moving away from GitHub

As part of my ongoing effort to gain more digital independence I decided to move away all my code from GitHub earlier this year. Up until then I was heavily invested in using GitHub but the shift towards AI scanning my code and the outages of the service with increasing frequency were the last straw that break's the camels back.

Migrating the repositories

No migration without a good plan. So I started to look what I would need to move over first. The repositories were pretty straightforward. I created a simple little script that would do the following:

  1. Get all private and public repositories via the GitHub CLI.

  2. Use the Forgejo API (/api/repos/migrate) to migrate each of the repos

  3. Delete the repository on GitHub via the GitHub CLI

However this simple migrating left one thing to be missed: my blog. Previously I was using GitHub Pages to host my blog. Of course using GitHub pages is a totally valid option but I wanted to migrate everything and therefore looked for alternatives. I found the Codeberg Pages offering but at the time of my migration this was not very stable and I wasn't so sure whether I should rely on it. Instead I opted for just hosting it by my own.

Migrating GitHub Pages to nginx

To keep things simple I used nginx with certbot for SSL certificate renewal as I already knew these tools and did not want to invest any further time into looking at alternatives like Caddy. In the end this is a very low volume static website and nginx will handle it totally fine. Since this post is about the migration to Forgejo I won't go much into detail here but I basically installed certbot and nginx, setup certbot with a cron job to automatically renew my certificate via LetsEncrypt and configured nginx with a basic HTTPS only configuration to serve a folder of static html files.

With automatic certificate renewing, the webserver and the firewall in place I could already upload a simple test HTML file and it worked flawlessly. However one key component was still missing: Deploying the actual blog.

Deploying the blog via Forgejo CI

One thing that I always liked about using GitHub Pages was the integration with GitHub actions to automatically deploy my blog whenever I make any changes. I use a custom static site generator I build in the programming language Swift which turns markdown files I write into the HTML you can see when browsing this very blog.

Since Forgejo Workflows are more or less compatible with GitHub actions creating the actual workflow configuration was pretty straightforward. 

# .forgejo/workflows/deploy.yml
on:
  push:
    branches:
      - main

enable-email-notifications: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
        - name: Checkout 🛎️
          uses: actions/checkout@v4 # https://code.forgejo.org/actions/checkout@v4
        
        - uses: actions/setup-swift@v2 # https://github.com/swift-actions/setup-swift@v2
          with:
            swift-version: "6.2"
          name: Setup Swift
       
        - name: Get Swift version
          run: swift --version
        
        - name: Build Site 🔧
          run: swift run
          shell: sh
      
        - name: Verify build output
          run: ls -la Site/
          shell: sh

        - name: Install rsync
          run: |
            apt-get update
            apt-get -yq install rsync
          shell: sh
      
        - name: Deploy via rsync
          run: |
            mkdir -p ~/.ssh
            echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
            chmod 600 ~/.ssh/id_rsa
            rsync -avz -vv --progress --delete -e "ssh -p ${{ secrets.REMOTE_PORT }} -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" Site/ ${{ secrets.REMOTE_USER }}@${{ secrets.REMOTE_HOST }}:${{ secrets.REMOTE_PATH }}
          shell: sh

The workflow builds the site with the Swift compiler and then writes the output via rsync to my web server. I had some issues getting the forgejo runner setup correctly especially finding and hosting the correct docker image for the runner (ubuntu-latest in this example configuration). Eventually I figured it out and then went one step ahead and replaced the actions above from pointing to remote URLs to my own actions repository. To consume these actions without the need to specify the host I updated my forgejo app instance configuration with the following: 

# gitea/conf/app.ini
[actions]
ENABLED = true
DEFAULT_ACTIONS_URL = https://mydomain.tld

This way I keep full control of what is running in my CI and am again a bit more independent in this whole process.

Let me know whether you recently did something similar. Did you encounter any issues? Do you have any questions regarding further details about the migration process? I am happy to hear from you.

Posted in homelab