CI/CI met gitea in docker compose (gegenereert door LM Studio:

Het koppelen van Gitea aan CI/CD is de overstap van “code hosten” naar “hele software lifecycle beheren”.

Je huidige setup draait perfect als broncodebeheer, maar hij heeft nog geen mechanisme om *actie* uit te voeren nadat er code verandert. Je hebt dus een Build Runner nodig.

Hier is een stapsgewijze uitleg van de concepten en hoe je dit in Docker Compose kunt implementeren.

Voordat we naar de code kijken, is het belangrijk om te begrijpen wat er gebeurt:

• De Trigger: Een ontwikkelaar pusht (pushes) code naar een branch in Gitea.
• De Webhook: Gitea detecteert deze push en stuurt automatisch een bericht (een *webhook*) naar een specifieke URL van jouw CI/CD-systeem.
• De Runner: Het CI/CD-systeem (de “Runner”) ontvangt het webhook, checkt de code uit, identificeert welke stappen moeten worden uitgevoerd (bijvoorbeeld: `npm install`, `npm test`, `docker build`).
• Executie: De Runner voert deze commando's in een schone, geïsoleerde omgeving (een container!) uit.

Jouw Taak: Je moet nu een nieuwe Docker-service toevoegen die de rol van de “Runner” op zich neemt en luistert naar webhooks.

Omdat er geen standaard, universele `ci_runner` image is dat alles kan, heb je twee opties:

Dit is een minimale service die alleen de trigger ontvangt en het concept laat zien. Je kunt hierbij een Python/Flask of Node.js/Express microservice gebruiken die simpelweg de webhook afhandelt en dan bijvoorbeeld een logboek genereert, om te bewijzen dat hij geactiveerd wordt.

Je kunt tools zoals Drone CI, of zelfs een specifieke GitLab Runner container gebruiken als je de complexiteit van het opzetten van een full-blown CI/CD platform aankunt.

*We gaan uit van Optie A, omdat dit het leerproces het meest toegankelijk houdt.*

We voegen een nieuwe service toe aan je bestand, bijvoorbeeld genaamd `ci_runner`.

Aanpassing in de `networks` sectie: Zorg ervoor dat alle diensten op hetzelfde netwerk draaien, zodat ze elkaar kunnen bereiken (wat al het geval is).

version: '3.8'

services:
    # --------------------
    # Huidige Gitea service
    # --------------------
    server:
        image: gitea/gitea:1.24
        container_name: gitea
        environment:
            - USER_UID=1000
            - USER_GID=1000
        restart: unless-stopped
        networks:
            - gitea
        volumes:
            - ./data:/data
            - /etc/timezone:/etc/timezone:ro
            - /etc/localtime:/etc/localtime:ro
        ports:
            - "3003:3000" # De 3003 poort is nu je web toegangspunt
            - "2222:22"
 
    # --------------------
    # NIEUWE CI/CD Runner Service
    # --------------------
    ci_runner:
        image: node:lts-slim # Gebruik een image met build tools (Node is vaak goed voor web apps)
        container_name: ci_runner
        restart: always
        environment:
            # Hier pas je credentials in, bijvoorbeeld de webhook secret key
            - WEBHOOK_SECRET=mijngeheimekey
        networks:
            - gitea
        volumes:
             # Hiermee kan de runner code uit checken (of een aparte repo volume)
            - ./runner_data:/work 
        ports:
            # De poort waarop Gitea naar zal communiceren
            - "5001:3000" # Exposeert de service op localhost:5001

networks:
    gitea:
        external: false

De container die je hebt geadd (`ci_runner`) moet nu een webserver draaien (bijvoorbeeld met Node.js/Express of Python/Flask) die luistert naar POST-requests op `/webhook`.

Dit is het pseudocode-idee voor wat in de `ci_runner` container draait:

• Luister: Start een HTTP server op poort 3000 (die je hebt geëxposeerd als 5001).
• Check Webhook: Wanneer een request binnenkomt, controleer dan of het bericht van Gitea is en of de `WEBHOOK_SECRET` klopt.
• Identificeer Event: Lees uit het payload (de body) wat er gebeurd is: Was het een `push`? Welke repository en welke branch?
• Uitvoeren: Als het een push is, voer dan de build stappen uit:

# Pseudocode voor execution inside the runner container
git checkout $GIT_BRANCH 
npm install # Installeert dependencies
npm run test # Voert tests uit
npm run build # Creëert artefacten (de deployable code)
echo "Build succesvol afgerond!" >> /var/log/ci.log

Nadat de `docker-compose up -d` is uitgevoerd en je weet dat je runner op het netwerk draait, moet je Gitea vertellen waar hij zijn webhooks moet sturen.

• Navigeer naar Gitea: Open de instellingen van je Gitea-instantie (meestal als admin).
• Webhooks Instellen (Per Repository): Ga naar de repository waar je wilt dat CI/CD draait.
• Creëer Webhook: Maak een nieuwe webhook aan.
  • URL: Je moet het interne netwerkadres van de runner gebruiken, bijvoorbeeld: `http://ci_runner:3000/webhook`
  • Trigger: Selecteer “Push” (of wat je wilt testen).
  • Secret: Voer dezelfde secret key in die je in de environment variabelen (`WEBHOOK_SECRET`) van je runner hebt ingesteld.

• Kies je technologie: Als je Node.js-projecten hebt, gebruik dan een Node runner. Voor Python projecten: `python:3.10-slim`.
• Bouw de logica: Schrijf de code die in die runner service draait om de stappen te automatiseren (checkout → install → test/build).

Door deze architectuur te volgen, heb je een volledig gecontaineriseerd CI/CD systeem: Gitea beheert het *wat*, en de Runner bepaalt het *hoe* en *wanneer*.