CI : ajouter les tests, déclencher sur push, compiler les trois binaires #48

New issue

Open

opened 2026-08-31 13:26:30 +00:00 by nicolas.boufideline · 0 comments

nicolas.boufideline commented

2026-08-31 13:26:30 +00:00

Owner

Contexte

Constaté en préparant #46 (relèvement du module en go 1.25). La CI actuelle tient en trois
workflows : release-pipeline.yml (orchestration), build.yml (compilation, appelé en
workflow_call) et release.yml (publication).

build.yml fait checkout → setup-go → go build → upload d'artefact. Et c'est tout.

Ce qui manque

1. Aucun test n'est exécuté par la CI

Il n'y a ni go test ni go vet dans aucun des trois workflows. La suite de tests du
projet n'a jamais été exécutée automatiquement.

Conséquence concrète et déjà vérifiée : #47 — panic: send on closed channel sur
internal/dispatcher/agent, reproductible une passe complète sur deux — vivait sur main sans
qu'aucun signal ne le remonte. Il a fallu monter une ligne de base à la main pour le voir.

2. Rien ne tourne avant la publication d'une release

Le seul déclencheur du pipeline est :

on:
  push:
    tags:
      - '[0-9]*.[0-9]*.[0-9]*'

Aucun workflow ne se déclenche sur un push de branche ni sur une ouverture de PR. La première
exécution de la CI pour un changement donné a donc lieu au moment où on publie, ce qui est
le pire moment pour découvrir une compilation cassée. C'est aussi ce qui rend toute modification
du pipeline lui-même impossible à valider autrement qu'en poussant un tag.

3. `cmd/db` n'est jamais compilé ni publié

La matrice de release-pipeline.yml ne liste que deux binaires :

binaries:
  - metadata
  - agent

Le projet en a trois — cmd/agent, cmd/metadata, cmd/db. db n'est donc ni construit par
la CI, ni publié en asset de release, alors que c'est l'outil d'inspection du store. À trancher :
oubli, ou choix délibéré de ne pas le livrer ?

4. La version de Go était épinglée en dur, et avait dérivé

build.yml déclarait go-version: "1.21" alors que le module était en go 1.24.0. Ça
fonctionnait — l'auto-download de toolchain (GOTOOLCHAIN=auto) télécharge la version demandée
par go.mod — mais le workflow affichait une version qui n'était pas celle qui compilait.

Corrigé dans la branche de #46 : go-version: "1.25.14". Reste que c'est une source de
dérive structurelle. La correction de fond est go-version-file: go.mod, qui fait de go.mod
la seule source de vérité. Elle n'a pas été appliquée tout de suite parce qu'un changement
d'input de setup-go n'est aujourd'hui validable qu'en poussant un tag (cf. point 2) : à faire
une fois le déclencheur sur push en place.

Propositions

Un job test : go test ./... et go vet ./..., déclenché sur push de branche et sur PR,
en plus du pipeline de release. C'est le point qui apporte le plus.
Compiler les trois binaires — ajouter db à la matrice si sa publication est souhaitée,
ou noter explicitement pourquoi il en est exclu.
Passer à go-version-file: go.mod une fois le job sur push en place, pour supprimer la
classe de dérive du point 4.
go build ./... en plus des builds par binaire : la matrice ne compile que
./cmd/<binari>, donc un paquet interne cassé mais non atteint depuis ces binaires passerait
inaperçu.
À considérer : -race sur le job de test. Les défauts de ce projet sont concurrents par
nature (workers, watchdog, arrêt de l'agent) — #47 en est l'illustration.

Périmètre

Outillage seul, aucun changement de code produit. Placé en next_feature faute de rattachement
à un jalon fonctionnel ; à remonter en 0.2.0 si on veut que le développement de #46 en bénéficie,
ce qui serait défendable.

## Contexte Constaté en préparant #46 (relèvement du module en `go 1.25`). La CI actuelle tient en trois workflows : `release-pipeline.yml` (orchestration), `build.yml` (compilation, appelé en `workflow_call`) et `release.yml` (publication). `build.yml` fait checkout → `setup-go` → `go build` → upload d'artefact. Et c'est tout. ## Ce qui manque ### 1. Aucun test n'est exécuté par la CI Il n'y a **ni `go test` ni `go vet`** dans aucun des trois workflows. La suite de tests du projet n'a jamais été exécutée automatiquement. Conséquence concrète et déjà vérifiée : **#47** — `panic: send on closed channel` sur `internal/dispatcher/agent`, reproductible une passe complète sur deux — vivait sur `main` sans qu'aucun signal ne le remonte. Il a fallu monter une ligne de base à la main pour le voir. ### 2. Rien ne tourne avant la publication d'une release Le seul déclencheur du pipeline est : ```yaml on: push: tags: - '[0-9]*.[0-9]*.[0-9]*' ``` Aucun workflow ne se déclenche sur un push de branche ni sur une ouverture de PR. La première exécution de la CI pour un changement donné a donc lieu **au moment où on publie**, ce qui est le pire moment pour découvrir une compilation cassée. C'est aussi ce qui rend toute modification du pipeline lui-même impossible à valider autrement qu'en poussant un tag. ### 3. `cmd/db` n'est jamais compilé ni publié La matrice de `release-pipeline.yml` ne liste que deux binaires : ```yaml binaries: - metadata - agent ``` Le projet en a trois — `cmd/agent`, `cmd/metadata`, `cmd/db`. `db` n'est donc ni construit par la CI, ni publié en asset de release, alors que c'est l'outil d'inspection du store. À trancher : oubli, ou choix délibéré de ne pas le livrer ? ### 4. La version de Go était épinglée en dur, et avait dérivé `build.yml` déclarait `go-version: "1.21"` alors que le module était en `go 1.24.0`. Ça fonctionnait — l'auto-download de toolchain (`GOTOOLCHAIN=auto`) télécharge la version demandée par `go.mod` — mais le workflow affichait une version qui n'était pas celle qui compilait. Corrigé dans la branche de #46 : `go-version: "1.25.14"`. Reste que **c'est une source de dérive structurelle**. La correction de fond est `go-version-file: go.mod`, qui fait de `go.mod` la seule source de vérité. Elle n'a pas été appliquée tout de suite parce qu'un changement d'input de `setup-go` n'est aujourd'hui validable qu'en poussant un tag (cf. point 2) : à faire une fois le déclencheur sur push en place. ## Propositions - **Un job `test`** : `go test ./...` et `go vet ./...`, déclenché sur push de branche et sur PR, en plus du pipeline de release. C'est le point qui apporte le plus. - **Compiler les trois binaires** — ajouter `db` à la matrice si sa publication est souhaitée, ou noter explicitement pourquoi il en est exclu. - **Passer à `go-version-file: go.mod`** une fois le job sur push en place, pour supprimer la classe de dérive du point 4. - **`go build ./...`** en plus des builds par binaire : la matrice ne compile que `./cmd/<binari>`, donc un paquet interne cassé mais non atteint depuis ces binaires passerait inaperçu. - À considérer : `-race` sur le job de test. Les défauts de ce projet sont concurrents par nature (workers, watchdog, arrêt de l'agent) — #47 en est l'illustration. ## Périmètre Outillage seul, aucun changement de code produit. Placé en `next_feature` faute de rattachement à un jalon fonctionnel ; à remonter en 0.2.0 si on veut que le développement de #46 en bénéficie, ce qui serait défendable.

nicolas.boufideline added this to the next_feature milestone

2026-08-31 13:26:30 +00:00

nicolas.boufideline added the

feature implementation

label

2026-08-31 13:26:30 +00:00

nicolas.boufideline referenced this issue from a commit

2026-09-05 21:16:56 +00:00

f-46: ci: align go version with the module #46

nicolas.boufideline referenced this issue from a commit

2026-09-05 21:18:20 +00:00

f-46: ci: align go version with the module #46