Skip to content

Forgejo-Runner

Podman
1 1 185
  • Nachdem ich ja hier einen Forgejo-Server aufgesetzt habe, den ich mittlerweile auch produktiv nutze, bin ich natürlich sehr schnell über Actions gestolpert.

    Mit Actions kann man verschiedene Prozesse automatisieren. z.B. das Testen seiner Repos, den Build Prozess usw.

    Doch wie macht man das?

    Dafür hat Forgejo ein Tool namens Forgejo-Runner. Die Anleitung für die Installation findet man -> https://forgejo.org/docs/latest/admin/runner-installation/

    97dfddb2-30f4-44a8-94c6-806ab3a47fd1-image.png

    Aus der Anleitung

    The Forgejo Runner is a daemon that fetches workflows to run from a Forgejo instance, executes them, sends back with the logs and ultimately reports its success or failure.

    It needs to be installed separately from the main Forgejo instance. For security reasons it is not recommended to install the runner on the same machine as the main instance.

    Ok, kann ich nicht auf dem Forgejo Server mitlaufen lassen 😞 Das Schöne an dem Runner ist, er kann auch lokal laufen, sprich auf meinem Proxmox 🙂

    Das bin ich dann mal angegangen. Ich wollte jetzt hier nicht wieder eine Anleitung schreiben, dazu gibt es im Netz genügend Informationen. Die Original Anleitung erklärt den Installationsprozess auch ausreichend gut, bis auf eine Kleinigkeit. Die Podman Einbindung habe ich nicht besonders gut hinbekommen, also hatte ich eine anstrengende Sitzung. Es hat lange gedauert, bis ich es hinbekommen habe.

    Systemd

    Im wesentlichen habe ich jetzt einen Debian 13 Trixie Server aufgesetzt, dieser hat Podman verpasst bekommen. Es gibt einen User runner und einen User docker. Zwei SystemD-Dienste habe ich angelegt.

    podman-docker-socket.service

    [Unit]
    Description=Podman Docker API Socket
    Documentation=man:podman-system-service(1)
    Wants=network-online.target
    After=network-online.target
    
    [Service]
    Type=simple
    ExecStart=/usr/bin/podman system service --time=0 unix:///var/run/docker.sock
    ExecStartPost=/bin/sh -c 'sleep 1 && chown root:docker /var/run/docker.sock && chmod 660 /var/run/docker.sock'
    Restart=always
    RestartSec=10
    
    [Install]
    WantedBy=multi-user.target
    

    forgejo-runner.service

    [Unit]
    Description=Forgejo Runner
    Documentation=https://forgejo.org/docs/latest/admin/actions/
    After=docker.service
    
    [Service]
    ExecStart=forgejo-runner daemon
    ExecReload=/bin/kill -s HUP $MAINPID
    
    # This user and working directory must already exist
    User=runner
    WorkingDirectory=/home/runner
    Restart=on-failure
    TimeoutSec=0
    RestartSec=10
    
    [Install]
    WantedBy=multi-user.target
    

    Der podman-docker-socket.service macht was?

    This command makes Podman listen on the standard Docker socket location (/var/run/docker.sock), which allows Docker clients and tools to communicate with Podman instead of Docker. Essentially, it lets you use Docker-compatible tools with Podman as the backend container engine.
    This is useful in environments where you want to use Podman instead of Docker (for security or other reasons) but still need compatibility with tools that expect to talk to Docker.
    @geklaut von claude.ai

    Ok, damit kann der Forgejo-Runner ganz normal seine Docker Befehle absetzen und Podman übernimmt dann.

    Auf meinem Server sieht das dann so aus

    pstree
    systemd─┬─agetty
            ├─cron
            ├─dbus-daemon
            ├─dhclient
            ├─forgejo-runner───7*[{forgejo-runner}]
            ├─podman───7*[{podman}]
            ├─qemu-ga───{qemu-ga}
            ├─sshd───sshd-session───sshd-session───bash───pstree
            ├─systemd───(sd-pam)
            ├─systemd-journal
            ├─systemd-logind
            ├─systemd-timesyn───{systemd-timesyn}
            └─systemd-udevd
    

    Wie man die Actions beim Runner registriert, ist in der Anleitung gut dokumentiert. Den Token dafür bekommt man auf dem Forgejo-Server.

    Token.png

    Wenn dann alles so weit funktioniert, kann man in seine Repos folgendes einbauen. Der Workflow dient zum Testen, ob alles gut funktioniert.

    .forgejo/workflows/test.yaml

    name: Test Runner
    
    on:
      push:
        branches: [ main ]
      workflow_dispatch:
    
    jobs:
      test:
        runs-on: docker
        container:
          image: debian:12
        steps:
          # Package duf installieren
          - name: Install package duf
            run: |
              apt-get update && apt-get install -y duf          
          - name: Test Connection
            run: |
              echo "Hello from Runner!"
              whoami
              hostname
              date
              duf
              echo "Environment is working!"
    

    Wenn man das dann pusht, startet der Workflow / Actions.

    4ac20208-c4f6-467d-b2b6-885956e1639f-image.png

    Am Ende sollte alles grün sein 🙂

    Man kann sich dann die Ausgabe ansehen, ob alles geklappt hat, wie man es erwartet.

    199bbdbd-b833-46af-b4d6-edd796ab28ff-image.png

    So weit bin ich zufrieden und kann mich damit jetzt weiter beschäftigen.

    Anmerkung

    Wie immer, wer Fehler oder Blödsinn findet, mag das bitte hier unten drunter schreiben. Ich ändere das dann gerne.

  • The #Forgejo monthly update was published ✨

    Uncategorized forgejo
    5
    0 Stimmen
    5 Beiträge
    19 Aufrufe
    frankm@nrw.socialF
    @Beowulf @heartshadows @jnk Perfect, thank you.
  • Redis ConnectionPool

    Redis redis linux ki-generiert
    2
    0 Stimmen
    2 Beiträge
    320 Aufrufe
    FrankMF
    Die Antwort von ChatGPT wie der Redis ConnectionPool funktioniert. Ein paar Dinge finde ich komisch. https://chat.openai.com/share/b10fdadc-2c9b-404a-bc99-c883d110d6af
  • Debian Bookworm 12.5 released

    Linux linux debian
    3
    0 Stimmen
    3 Beiträge
    251 Aufrufe
    FrankMF
    Und hier taucht es dann auf -> https://www.debian.org/News/2024/20240210
  • Nextcloud - extrem lange Ladezeiten

    Nextcloud nextcloud code linux
    1
    1
    0 Stimmen
    1 Beiträge
    189 Aufrufe
    Niemand hat geantwortet
  • Semaphore - Installation & Anwendung

    Verschoben Ansible semaphore ansible linux
    4
    9
    0 Stimmen
    4 Beiträge
    2k Aufrufe
    FrankMF
    Ich parke das mal hier, damit ich das nicht noch mal vergesse. Hat mich eben mal wieder eine Stunde gekostet /etc/ansible/ansible.cfg [defaults] host_key_checking = False Edit -> https://linux-nerds.org/topic/1493/ansible-host_key_checking
  • checkmk - Agent auf einem Debian Buster Server installieren

    Verschoben checkmk checkmk linux
    1
    2
    0 Stimmen
    1 Beiträge
    817 Aufrufe
    Niemand hat geantwortet
  • LUKS verschlüsselte Platte mounten

    Linux linux
    2
    1
    0 Stimmen
    2 Beiträge
    1k Aufrufe
    FrankMF
    So, jetzt das ganze noch einen Ticken komplizierter Ich habe ja heute, für eine Neuinstallation von Ubuntu 20.04 Focal eine zweite NVMe SSD eingebaut. Meinen Bericht zu dem Thema findet ihr hier. Aber, darum soll es jetzt hier nicht gehen. Wir haben jetzt zwei verschlüsselte Ubuntu NVMe SSD Riegel im System. Jetzt klappt die ganze Sache da oben nicht mehr. Es kommt immer einen Fehlermeldung. unbekannter Dateisystemtyp „LVM2_member“. Ok, kurz googlen und dann findet man heraus, das es nicht klappen kann, weil beide LVM Gruppen, den selben Namen benutzen. root@frank-MS-7C37:/mnt/crypthome/root# vgdisplay --- Volume group --- VG Name vgubuntu2 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size <464,53 GiB PE Size 4,00 MiB Total PE 118919 Alloc PE / Size 118919 / <464,53 GiB Free PE / Size 0 / 0 VG UUID lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A --- Volume group --- VG Name vgubuntu System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size <475,71 GiB PE Size 4,00 MiB Total PE 121781 Alloc PE / Size 121781 / <475,71 GiB Free PE / Size 0 / 0 VG UUID jRYTXL-zjpY-lYr6-KODT-u0LJ-9fYf-YVDna7 Hier oben sieht man das schon mit geändertem Namen. Der VG Name muss unterschiedlich sein. Auch dafür gibt es ein Tool. root@frank-MS-7C37:/mnt/crypthome/root# vgrename --help vgrename - Rename a volume group Rename a VG. vgrename VG VG_new [ COMMON_OPTIONS ] Rename a VG by specifying the VG UUID. vgrename String VG_new [ COMMON_OPTIONS ] Common options for command: [ -A|--autobackup y|n ] [ -f|--force ] [ --reportformat basic|json ] Common options for lvm: [ -d|--debug ] [ -h|--help ] [ -q|--quiet ] [ -v|--verbose ] [ -y|--yes ] [ -t|--test ] [ --commandprofile String ] [ --config String ] [ --driverloaded y|n ] [ --nolocking ] [ --lockopt String ] [ --longhelp ] [ --profile String ] [ --version ] Use --longhelp to show all options and advanced commands. Das muss dann so aussehen! vgrename lpZxyv-cNOS-ld2L-XgvG-QILa-caHS-AaIC3A vgubuntu2 ACHTUNG Es kann zu Datenverlust kommen, also wie immer, Hirn einschalten! Ich weiß, das die erste eingebaute Platte mit der Nummer /dev/nvme0n1 geführt wird. Die zweite, heute verbaute, hört dann auf den Namen /dev/nvme1n1. Die darf ich nicht anpacken, weil sonst das System nicht mehr startet. /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> /dev/mapper/vgubuntu-root / ext4 errors=remount-ro 0 1 # /boot was on /dev/nvme1n1p2 during installation UUID=178c7e51-a1d7-4ead-bbdf-a956eb7b754f /boot ext4 defaults 0 2 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=7416-4553 /boot/efi vfat umask=0077 0 1 /dev/mapper/vgubuntu-swap_1 none swap sw 0 0 Jo, wenn jetzt die Partition /dev/mapper/vgubuntu2-root / anstatt /dev/mapper/vgubuntu-root / heißt läuft nichts mehr. Nur um das zu verdeutlichen, auch das könnte man problemlos reparieren. Aber, ich möchte nur warnen!! Nachdem die Änderung durchgeführt wurde, habe ich den Rechner neugestartet. Puuh, Glück gehabt, richtige NVMe SSD erwischt Festplatte /dev/mapper/vgubuntu2-root: 463,58 GiB, 497754832896 Bytes, 972177408 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Nun können wir die Platte ganz normal, wie oben beschrieben, mounten. Nun kann ich noch ein paar Dinge kopieren
  • ReactPHP auf einem ROCKPro64 testen

    Linux reactphp linux composer
    1
    1
    0 Stimmen
    1 Beiträge
    214 Aufrufe
    Niemand hat geantwortet