Table of Contents
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.
💡 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).
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
⚙️ 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:
# 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
✅ 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
| Component | Wat doet het? | Docker Compose Service | Poort (Intern) |
|---|---|---|---|
| Source Code | Host en triggert events (webhooks). | `server` (Gitea) | 3000 |
| Trigger Mechanism | Ontvangt webhooks van Gitea. | `ci_runner` | 3000 |
| Build/Executie | Voert de geautomatiseerde stappen uit. | Binnen de logica van `ci_runner` (via Git/npm/etc.) | N.v.t. |
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*.
