### CI/CD — Fonctionnement observé et architecture de déploiement

Cette documentation décrit le pipeline CI/CD tel qu’il peut être déduit des artefacts présents dans le dépôt : `Dockerfile`, `package.json`, et les manifestes Kubernetes rendus dans `temp.yaml`. Aucune configuration de pipeline explicite n’est présente dans le dépôt (pas de `.gitea/`, `.github/workflows/`, `.gitlab-ci.yml`, `.drone.yml`). Le flux ci-dessous s’appuie donc sur ces éléments pour décrire le fonctionnement attendu.

### Portée

- **Build applicatif**: Next.js (Node 19-alpine) avec dépendance privée `le-coffre-resources` via SSH.
- **Image Docker**: construction multi-étapes, publication vers le registre Docker hébergé sur `git.4nkweb.com` (accès via clés SSH).
- **Déploiement Kubernetes**: namespace `lecoffre`, intégration Vault Agent pour l’injection d’ENV, `ExternalSecret` pour le secret de pull Docker, `Ingress` TLS via cert-manager, ressources de `Deployment`/`Service`.
 - **Variables front ajoutées**: `NEXT_PUBLIC_4NK_IFRAME_URL` pour distinguer l’URL complète de l’iframe de son origin (`NEXT_PUBLIC_4NK_URL`).

### Chaîne de build

- **Dépendances**
  - `package.json` indique Next.js 14, TypeScript 4.9, ESLint 8.36, etc.
  - La dépendance privée `le-coffre-resources` est récupérée depuis `git.4nkweb.com` via SSH (`git+ssh`).

- **Dockerfile** (multi-étapes, Node 19-alpine)
  - Étape `deps`: installation des dépendances avec `npm install` en utilisant BuildKit et le forward d’agent SSH pour accéder au dépôt privé.
  - Étape `development`: copie du code, exécution sous un utilisateur non-root, commande par défaut `npm run dev` (pour le développement local). Pour la prod, l’image utilisée en cluster exécute `npm run start` (cf. manifeste).

- **Build Next.js**
  - Script `build`: `NEXT_TELEMETRY_DISABLED=1 next build --no-lint`
  - Script `start`: `next start`
  - Le lint n’est pas bloquant au build (flag `--no-lint`).

### Image, registre et version

- **Registre**: Docker registry interne sur `git.4nkweb.com`.
- **Tagging**: contrôlé par la CI via le message de commit (préfixe `ci: docker_tag=<valeur>`), sinon fallback `dev-test`. La branche peut être utilisée comme tag par défaut selon la CI. Recommandation: utiliser un tag non versionné `int-dev`.

### Déploiement Kubernetes (extrait de `temp.yaml`)

- **Namespace**: `lecoffre`
- **ServiceAccount**: `lecoffre-front-sa` avec `Secret` token associé.
- **ExternalSecret**: création de `imagePullSecret` à partir de Vault via `external-secrets.io` en lisant `secret/data/lecoffre-front-stg/config/dockerpullsecret` (clé `.dockerconfigjson`).
- **Deployment**: `apps/v1` nommé `lecoffre-front` avec:
  - `image`: `rg.fr-par.scw.cloud/lecoffre/front:v0.1.9`
  - `imagePullPolicy`: `Always`
  - `resources`: `requests` (cpu 200m, ram 1Gi), `limits` (ram 2Gi)
  - **Vault Agent Injector**: annotations pour injecter des variables d’environnement depuis `secret/data/lecoffre-front-stg/config/envs` en exportant chaque paire `clé=valeur` dans `/vault/secrets/envs`.
  - **Commande de démarrage**: `['sh','-c', '. /vault/secrets/envs && npm run start']`

- **Service**: type ClusterIP exposant le port 80 vers le `targetPort` 3000 du conteneur Next.js.

- **Ingress**: classe `nginx` avec TLS géré par `cert-manager` (ClusterIssuer `letsencrypt-prod`) pour `app.stg.lecoffre.smart-chain.fr`.

### Flux CI/CD attendu (déduit)

1. **Checkout + préparation**
   - Récupération du code et configuration de l’agent SSH (accès à `git.4nkweb.com`).

2. **Installation des dépendances**
   - `npm install` avec BuildKit (`--mount=type=ssh`) pour la dépendance privée.

3. **Build applicatif**
   - `npm run build` (désactive la télémétrie et le lint bloquant).

4. **Construction de l’image**
   - Réalisée par la CI (BuildKit + forward d’agent SSH) après un `git push` sur `git.4nkweb.com`.
   - Taggage déterminé par le message de commit et/ou la branche.

5. **Push au registre**
   - Réalisé par la CI vers le registre `git.4nkweb.com`.

6. **Déploiement Kubernetes**
   - Application des manifestes (ou rendu Helm) dans le namespace `lecoffre`.
   - Les secrets de pull sont fournis via `ExternalSecret` connecté à Vault.
   - Au runtime, Vault Agent injecte les variables d’environnement nécessaires avant `npm run start`.

### Sécurité et secrets

- **Build**: le forward d’agent SSH évite d’écrire la clé privée dans l’image.
- **Runtime**: aucune variable sensible n’est stockée dans l’image; elles sont injectées à l’exécution par Vault.
- **Pull de l’image**: la config Docker (`.dockerconfigjson`) est fournie par `ExternalSecret` à partir de Vault.

### Secrets CI requis

- **USER**: identifiant du compte CI sur `git.4nkweb.com` disposant des droits requis (lecture repo, push d’image vers le registry).
- **TOKEN**: jeton d’accès (API/registry) associé à `USER`. Utilisé par la CI pour:
  - Authentifier les actions git/HTTP vers `git.4nkweb.com` (si nécessaire)
  - Authentifier le `docker login` vers le registry Gitea si la CI ne repose pas sur des credentials intégrés.

Notes:
- Préférer des tokens à portée restreinte, régénérés périodiquement.
- Stocker `USER` et `TOKEN` dans le gestionnaire de secrets CI et ne jamais les committer.

### Points à confirmer

- Outil CI utilisé (Gitea Actions, Woodpecker/Drone, GitLab CI, autre) et fichiers de pipeline hébergés ailleurs.
- Règles de nommage des tags d’image et gouvernance de version (`vX.Y.Z`, tags d’environnement).
- Stratégie de déploiement (Helm chart source exact, commandes d’apply, gestion multi-env: dev/stg/prod).
- Politique de lint/test avant build (actuellement `--no-lint` au build Next.js).
 - Passage des variables `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` à l’étape de build Docker (ARG/ENV) dans la CI.

### Bonnes pratiques recommandées

- Activer un job de lint et tests unitaires avant build d’image.
- Signer les images (Cosign) et activer des scans SCA/Container.
- Gérer explicitement les tags et le changelog en CI.
- Déployer via Helm chart versionné, avec valeurs par environnement (`values.{env}.yaml`).

### Validation de l'image Docker « int-dev » (intégration des variables)

- Objectif: vérifier que les variables `NEXT_PUBLIC_*` sont bien injectées dans l'image construite par la CI.
- Commande:

```
docker pull git.4nkweb.com/4nk/lecoffre-front:int-dev
docker run --rm git.4nkweb.com/4nk/lecoffre-front:int-dev sh -lc "env | grep '^NEXT_PUBLIC_' | sort"
```

- Attendus clés:
  - `NEXT_PUBLIC_4NK_URL` et `NEXT_PUBLIC_4NK_IFRAME_URL` doivent être définies.
  - Les URLs API (`NEXT_PUBLIC_API_URL`, `NEXT_PUBLIC_BACK_API_*`) doivent refléter l'environnement.