Verhaar_Wiki

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

====== CI/CI met gitea in docker compose: ======

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.

----

=== 💡 Conceptueel Overzicht: Hoe werkt CI/CD met Gitea? ===

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.

==== 🚀 Stap 1: De CI/CD Runner Implementeren ====

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

=== Optie A (Aanbevolen voor leren): Een Simpele Webhook Listener ===
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.

=== Optie B (Professioneel): Een Bestaand CI Tool Gebruiken ===
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.***

==== 🛠️ Stap 2: De `docker-compose.yaml` Aanpassen ====

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).

<code yaml>
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
</code>

==== ⚙️ Stap 3: Implementatie van de Runner Logica (Code) ====

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:

<code bash>
# 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
</code>

==== ✅ Stap 4: Gitea Configureren en Connecteren ====

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.

==== 🌟 Samenvatting & Volgende Stappen ====

==== Wat nu? ====

* **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*.

Edit summary