adam/tripoli.cloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tripoli.cloud/ci
History
Adam Belkacemi c6aa75ba39
All checks were successful
CI / build-and-test (push) Successful in 2m34s
Details
CI / deploy (push) Successful in 3m8s
Details
CI/CD : Forgejo Actions (pas GitLab - le dépôt vit sur Forgejo) 
- .forgejo/workflows/ci.yml : build + test cargo (workspace), build npm
  (app/) sur toute PR/push ; déploiement (main uniquement) : build
  release, scp + redémarrage systemd sur tripoli-edge et tripoli-api.
- Runner Forgejo Actions déployé en systemd (aucun n'existait avant) :
  socket Docker de l'hôte partagé avec les conteneurs de job plutôt
  qu'un docker:dind imbriqué et privilégié - plus léger sur une machine
  déjà partagée.
- Déploiement via un compte système "deploy" sans privilège : peut
  seulement déposer un binaire dans /opt/deploy-staging et lancer un
  script sudo dédié qui n'accepte que "tripoli-edge" ou "tripoli-api"
  comme argument. Aucune clé root dans le pipeline. Clé SSH de
  déploiement générée sur le serveur, jamais passée par cette
  conversation - stockée directement comme secret Forgejo Actions par
  l'utilisateur.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-17 13:30:36 +02:00
..
forgejo-runner.service CI/CD : Forgejo Actions (pas GitLab - le dépôt vit sur Forgejo) 2026-09-17 13:30:36 +02:00
README.md CI/CD : Forgejo Actions (pas GitLab - le dépôt vit sur Forgejo) 2026-09-17 13:30:36 +02:00

README.md

CI/CD

Le brief demandait un .gitlab-ci.yml, mais ce dépôt vit sur Forgejo, pas GitLab (voir le README racine) : l'équivalent réel est un workflow Forgejo Actions (.forgejo/workflows/ci.yml), syntaxe compatible GitHub Actions.

Runner

Aucun runner Forgejo Actions n'existait sur ce serveur avant cette phase. Déployé en systemd (forgejo-runner.service), conteneur code.forgejo.org/forgejo/runner:13.1, socket Docker de l'hôte partagé avec les conteneurs de job (docker_host: "automount" dans sa config) plutôt qu'un docker:dind imbriqué et privilégié - plus léger sur une machine à 3.7 Go déjà partagée, au prix d'une isolation plus faible (un job de CI a accès au docker de l'hôte). Acceptable ici : instance Forgejo mono-utilisateur, pas un service ouvert à des tiers.

Déploiement : un compte dédié, pas root

Le pipeline ne se connecte jamais en root. Un utilisateur système deploy existe uniquement pour :

  1. recevoir le binaire compilé par scp dans /opt/deploy-staging/ ;
  2. lancer sudo /usr/local/sbin/tripoli-deploy.sh <service> - un script sudo dédié (voir /etc/sudoers.d/deploy sur le serveur) qui n'accepte que tripoli-edge ou tripoli-api comme argument, installe le binaire à l'emplacement attendu et redémarre exactement ce service. Rien d'autre n'est accessible via ce compte.

La clé privée correspondante est stockée comme secret Forgejo Actions (DEPLOY_SSH_KEY), jamais dans ce dépôt.

Workflow (.forgejo/workflows/ci.yml)

  • build-and-test (toute PR et push) : installe Rust via rustup (l'image du job, node:20-bookworm, a un rustc système trop ancien pour ce code), cargo build --workspace, cargo test --workspace, puis npm ci && npm run build pour le frontend.
  • deploy (uniquement sur main, après succès du job précédent) : build release, puis dépôt + redémarrage de tripoli-edge et tripoli-api via le compte deploy.

tripoli-netctl et le labo bird-lab ne sont pas déployés par ce pipeline : ce sont des outils de labo qu'on lance à la main, pas des services qui tournent en continu.