# CI/CD — dépôt `ansible-hardening-linux`

Même principe qu'`ansible-centreon` : Gitea **contrôle** le code, Semaphore **l'exécute**.
Une différence : Semaphore ne suit pas `main` mais la branche **`valide`**, qui n'avance
que depuis `main` et seulement après un contrôle réussi. Un commit qui casse le lint
n'atteint donc jamais Semaphore.

```
push / PR sur main ──► controle : yamllint, syntax-check, ansible-lint, clés présentes
                              │ succès (push sur main uniquement)
                              ▼
                       promouvoir : main ──► valide
                              │
                              ▼
            Semaphore (dépôt sur branche « valide ») exécute site.yml
```

## Contrôle du code — Gitea Actions

`.gitea/workflows/ansible-lint.yml`, job `controle`, sur chaque pull request et chaque
push vers `main` :

| Étape | Ce qu'elle attrape |
|---|---|
| `yamllint .` | indentation, lignes trop longues, valeurs booléennes douteuses |
| `ansible-playbook site.yml --syntax-check` + `--list-tasks` | playbook ou rôle cassé, tâche mal formée, variable manquante dans les rôles |
| `ansible-lint` | mauvaises pratiques, modules dépréciés, tâches sans `changed_when` — profil `production` |
| clés présentes | un répertoire `files/keys/<compte>/` sans fichier `.pub` verrouillerait ce compte |

`vault.yml` étant chiffré, le syntax-check utilise `vault.yml.example` à sa place si le
mot de passe n'est pas disponible dans la CI (il ne l'est pas, volontairement).

## Promotion — job `promouvoir`

Sur un push validé sur `main`, le job pousse le même commit sur `valide`. Il lui faut :

- un secret de dépôt **`GITEA_TOKEN_PROMOTION`** : jeton d'un compte (de préférence un
  compte technique) autorisé à écrire sur `valide` ;
- la branche `valide` **protégée** dans Gitea, avec ce seul compte en liste blanche de
  push, pour qu'aucun humain ne puisse y pousser directement.

## Exécution — Semaphore

À créer une fois dans le projet Semaphore :

- **Dépôt** : l'URL Gitea de `ansible-hardening-linux`, branche **`valide`**.
- **Clé SSH** : la clé privée du compte de connexion (`ansible` avec sudo, ou `root`
  comme sur les VM Terraform). Sa clé publique doit figurer dans
  `files/keys/<compte>/` — c'est ce que vérifie le rôle `ssh` avant de durcir.
- **Mot de passe du vault** : entrée dédiée du magasin de clés, pointée par le modèle
  de tâche, ou `ANSIBLE_VAULT_PASSWORD_FILE` dans l'environnement du modèle.
- **Inventaire** : `inventory/hosts.yml` du dépôt (versionné), ou un inventaire
  Semaphore si les hôtes changent souvent.
- **Modèle `Simulation`** : `site.yml` avec `--check --diff` — à utiliser pour tout
  premier passage sur un hôte.
- **Modèle `Configuration`** : `site.yml`.
- **Modèle `SSH seul`** : `site.yml --tags ssh`, pratique pour la rotation des clés.

Semaphore installe les collections de `collections/requirements.yml` avant chaque exécution.

## Secrets

Rien de secret ne transite par Gitea : les communautés SNMP et les mots de passe SNMPv3
sont dans `group_vars/all/vault.yml`, chiffré, et seul Semaphore détient le mot de passe
du vault. Les clés publiques SSH et les certificats racine sont versionnés en clair :
ce sont des éléments publics.