Vérifier une modification avant de la fusionner

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# Vérifier une modification avant de la fusionner

Sidekicks n'a pas de CI : les vérifications se font sur votre machine. Ce guide montre quoi lancer avant de fusionner une branche dans `main`. Il suppose les outils de [Développer l'application](developper-l-application.md) et un terminal ouvert à la racine du dépôt.

## Étapes

1. **Indexez ou commitez votre modification**, bindings compris (`git add -A`). La vérification des bindings compare les bindings régénérés à ce que git connaît, pas à votre copie de travail.
2. **Lancez toutes les vérifications** :

   ```bash
   make verify
   ```

   La commande lance `make check` — golangci-lint, svelte-check, les en-têtes de licence, puis les tests Go, frontend et shell — puis `make bindings-check` : les bindings TypeScript sont régénérés et doivent être identiques à ceux indexés. Un passage réussi se termine par :

   ```text
   all tag-release tests passed
   ```

   sans sortie de `git diff`.
3. **Si la vérification des bindings échoue** : les services ou les événements ont changé sans `make bindings`. La régénération vient de mettre à jour `frontend/bindings` : indexez-les (`git add frontend/bindings`) et relancez `make verify`.
4. **Vérifiez aussi sous Linux**, depuis le Mac, quand la modification touche les terminaux, les workspaces, les scripts shell ou le build :

   ```bash
   make check-linux
   ```

   La commande lance `make check` dans un conteneur ubuntu:26.04 avec GTK 4 et WebKitGTK 6 (Docker doit tourner ; le premier lancement construit l'image, environ 2,6 Go).
5. **Fusionnez** dans `main`.

## Variantes

- **La modification touche ACP, les agents ou les channels** : lancez aussi les tests avec les vrais agents, `make test-real` (demande `mm` et llmman ; voir [Lancer les tests](lancer-les-tests.md#lancer-les-tests-avec-les-vrais-agents)).
- **La modification se voit dans l'interface** : `make dev` et essayez-la ; pour une release, les [scénarios de bout en bout](derouler-les-scenarios-de-bout-en-bout.md).
- **Vérifier automatiquement avant chaque push** : installez une fois un hook git —

  ```bash
  printf '#!/bin/sh\nexec make verify\n' > .git/hooks/pre-push && chmod +x .git/hooks/pre-push
  ```

  `git push --no-verify` le saute au besoin (pour pousser un tag, par exemple).
- **Linux x86-64 depuis un Mac Apple Silicon** : `LINUX_ARCH=amd64 make check-linux` (émulé, donc plus lent).
- **Sous Linux** : `make verify` suffit ; `make check-linux` est pour le Mac.

## Voir aussi

- [Lancer les tests](lancer-les-tests.md) — partie par partie, vrais agents, conteneurs
- [Référence : commandes](../reference/commandes.md) — toutes les cibles `make`
- [RELEASING.fr.md](../../../RELEASING.fr.md) — une fois `main` prête à être publiée