prestashop-test/docs-bonne-pratiqueCI/infra-ci.md

Infra CI — Gitea, Woodpecker server, Woodpecker agent

---

Gitea (git.open.us.org)

Forge Git. Héberge les dépôts et émet les webhooks vers Woodpecker.

Contrainte critique : dépôt public obligatoire

Woodpecker injecte le token OAuth de l'utilisateur pour git clone (via netrc) uniquement pour les repos marqués private=true dans sa DB. Ce token est au format JWT (eyJhbGci...) — accepté par l'API Gitea (Bearer) mais rejeté pour git over HTTPS (Basic auth). Résultat : exit 128 "could not read Username" au step clone.

Règle : rendre le dépôt public sur Gitea. Le clone se fait anonymement, sans token. Le dépôt public ne pose aucun problème de sécurité si aucun secret n'est committé (les secrets sont dans Woodpecker Secrets et dans .gitignore).

Alternative si le dépôt doit rester privé : remplacer le token JWT par un Personal Access Token (PAT) Gitea (format hex) directement dans la DB Woodpecker :

PGPASSWORD=<pw> psql -h localhost -U woodpecker woodpecker -c \
  "UPDATE users SET access_token='<PAT-hex>', refresh_token='', expiry=9999999999 WHERE login='syoul';"
sudo systemctl restart woodpecker

Configurer un nouveau dépôt

1. Créer le dépôt sur git.open.us.org
2. Le rendre public (Settings > Danger Zone > Visibility)
3. Woodpecker détecte automatiquement les dépôts Gitea de l'utilisateur connecté via OAuth

---

Woodpecker server (open.us.org)

Orchestre les pipelines, expose l'UI et l'API. Tourne en systemd (pas Docker).

Service : woodpecker (systemd)
Config  : /etc/woodpecker/woodpecker.env  (ou /etc/default/woodpecker)
DB      : PostgreSQL localhost:5432/woodpecker
          user: woodpecker, pw: voir DB

Variables d'environnement clés :

WOODPECKER_DATABASE_DRIVER=postgres
WOODPECKER_GITEA_URL=https://git.open.us.org
WOODPECKER_GITEA_CLIENT=<oauth-client-id>
WOODPECKER_GITEA_SECRET=<oauth-secret>
WOODPECKER_AGENT_SECRET=<shared-secret-avec-agent>

Activer un dépôt dans Woodpecker

1. UI Woodpecker > + (Add repository) > sélectionner le dépôt Gitea
2. Woodpecker installe un webhook sur Gitea automatiquement
3. Les secrets se configurent dans Settings > Secrets du dépôt

---

Woodpecker agent (sonic)

Exécute les steps de pipeline dans des containers Docker sur sonic. Tourne en Docker (container woodpecker-agent).

Container : woodpecker-agent
Config    : variables d'env dans docker-compose ou .env
Socket    : /var/run/docker.sock (monté pour lancer les steps)

Variables d'environnement clés :

WOODPECKER_SERVER=<adresse-du-server>:9000   # gRPC
WOODPECKER_AGENT_SECRET=<shared-secret>      # doit correspondre au server
WOODPECKER_MAX_WORKFLOWS=4                   # parallélisme

Workspace des steps

Chaque pipeline a un workspace (dossier partagé entre tous ses steps).

• Le workspace est monté dans chaque step container
• /tmp n'est pas partagé entre steps — utiliser le workspace (.reports/, .env.deploy, etc.)
• Le CWD initial de chaque step est la racine du workspace (= racine du dépôt cloné)

Volumes montés disponibles sur sonic

Chemin hôte	Usage
/var/run/docker.sock	Contrôle Docker depuis un step
/opt/prestashop	Données de déploiement PrestaShop
/home/syoul/trivy-cache	Cache DB CVE Trivy (~200 Mo, évite re-téléchargement)

/opt/trivy-cache nécessite sudo (non disponible) — utiliser /home/syoul/trivy-cache.

---

Dependency-Track (dtrack.syoul.fr)

Plateforme SBOM centralisée. Reçoit les SBOM CycloneDX via API, surveille les CVE en continu. Déployé sur sonic via Docker Compose dans /opt/dtrack/.

Créer et configurer le token API

1. https://dtrack.syoul.fr → login admin / admin → changer le mot de passe
2. Administration > Access Management > Teams > Automation
3. Onglet Permissions : ajouter BOM_UPLOAD + PROJECT_CREATION
4. Onglet API Keys > + → copier la clé
5. Woodpecker UI > dépôt > Settings > Secrets > dependency_track_token → coller la clé

Secret Woodpecker requis

Secret	Valeur
dependency_track_token	API key de l'équipe Automation

Voir ../docs-sbom/integration-nouvelle-app.md pour les 3 steps SBOM à copier dans la pipeline.