# Pipeline Gitea: `DEV_build_deploy.yaml`

## Scopo
Questa pipeline esegue build, publish immagini Docker e deploy Kubernetes dell'ambiente `dev`.

Flusso alto livello:
1. Checkout del repository.
2. Login al registry Harbor.
3. Build e push delle immagini per ogni servizio in `containers/*`.
4. Creazione del file `kubeconfig` da secret.
5. Sostituzione variabili nei manifest Kubernetes.
6. Deploy dei manifest e configurazione listener HTTPS sul Gateway.

## Trigger e runner
- Trigger: `push` su branch `main`.
- Job: `docker`.
- Runner richiesto: `POC-Master0`.

## Definizione pipeline
File: `pipeline/DEV_build_deploy.yaml`

Step principali:
- `actions/checkout@v4`
- `docker/login-action@v3`
- `/root/work/pipeline/build_container.sh ${{ github.event.repository.name }} ${{ vars.REGISTRY }}`
- creazione `./kubeconfig` da `${{ secrets.KUBECONFIG_DEV }}`
- `/root/work/pipeline/customize.sh dev`
- `/root/work/pipeline/deploy.sh`

## Script eseguiti dalla pipeline

### 1) `build_container.sh`
Responsabilità:
- Itera tutte le directory `containers/*/`.
- Copia i sorgenti da `src/<container>/` dentro `containers/<container>/`.
- Rileva il Dockerfile (`dockerfile` oppure `Dockerfile`).
- Costruisce due tag immagine:
  - `${REGISTRY_URL}/${REPO_NAME}/${CONTAINER_NAME}:${COMMIT_SHA}`
  - `${REGISTRY_URL}/${REPO_NAME}/${CONTAINER_NAME}:latest`
- Esegue push su registry.
- Scrive su file `./imglist` una riga per container:
  - `IMAGE_TAG_<container>=<image-tag-con-sha>`

Supporto multi-arch:
- Se presente `containers/<container>/platform.conf` con chiave `platform=...`, usa `docker buildx build --platform ... --push`.
- In assenza di `platform.conf` usa `docker build` + `docker push` classico.

Input (argomenti):
- `$1`: `REPO_NAME` (passato dalla pipeline con `${{ github.event.repository.name }}`).
- `$2`: `REGISTRY_URL` (passato da `${{ vars.REGISTRY }}`).

Prerequisiti runtime:
- Docker daemon disponibile nel runner.
- Permessi push su registry.
- Struttura cartelle coerente tra `containers/` e `src/`.

### 2) `customize.sh`
Responsabilità funzionale attesa:
- Carica variabili da:
  - `env/<ENV>/values.env`
  - `properties.env`
  - file temporaneo con:
    - `TAG=<commit_sha>`
    - contenuto di `imglist` (generato da `build_container.sh`)
- Cerca tutti i manifest `kubernetes/**/*.yaml`.
- Esegue sostituzione placeholder nel formato `<CHIAVE>` con i valori trovati.

Input (argomenti):
- `$1`: ambiente (`dev|qa|prod`).
  - In pipeline attuale viene usato `dev`.

Placeholder parametrizzabili nei manifest:
- Tutte le chiavi presenti in `env/<ENV>/values.env`.
- Tutte le chiavi presenti in `properties.env`.
- `TAG`.
- `IMAGE_TAG_<container>` (una per ciascun container buildato).

Output:
- Manifest Kubernetes in-place con valori sostituiti.

### 3) `deploy.sh`
Responsabilità:
- Cerca manifest CNPG (`apiVersion: postgresql.cnpg.io/v1`).
- Se trovato:
  - Estrae `metadata.name` del cluster PostgreSQL.
  - Ricava namespace dal role `namespace-deployer` nel cluster.
  - Crea/aggiorna ConfigMap `service-config` con:
    - `tipodb=postgres`
    - `urldb=<pg_name>.<namespace>.svc.cluster.local`
- Applica tutti i manifest YAML trovati in `kubernetes/` (directory per directory).
- Invoca `/root/work/pipeline/addlistener.sh` per configurare listener HTTPS sul Gateway.

Prerequisiti runtime:
- `kubectl` disponibile nel runner.
- `./kubeconfig` presente e valido.
- Opzionale `yq` (se assente, usa fallback con `awk` per estrazione nome CNPG).

### 4) `addlistener.sh`
Responsabilità:
- Legge la chiave `endpoint` da `properties.env`.
- Calcola token host-based dal dominio.
- Invoca `/root/work/pipeline/add-listener.sh` passando:
  - `<endpoint>`
  - `https-<token>`
  - `<token>-secret`

Input (argomenti):
- `$1` opzionale: path file properties (default `properties.env`).

Comportamento:
- Se file non esiste o `endpoint` non valorizzato: termina senza errore bloccante (`exit 0`).

### 5) `add-listener.sh`
Responsabilità:
- Effettua patch JSON sulla risorsa Gateway Kubernetes:
  - Gateway: `main-gateway`
  - Namespace: `nginx-gateway`
- Aggiunge un listener HTTPS con certificato TLS da Secret.
- Verifica idempotenza per `name` e `hostname` già presenti.

Input (argomenti):
- `$1`: `hostname`
- `$2`: `name`
- `$3`: `secret-name`

## Parametrizzazione complessiva

### Variabili Gitea Actions
- `vars.REGISTRY`: URL registry target.

### Secret Gitea Actions
- `secrets.HARBOR_USERNAME`
- `secrets.HARBOR_PASSWORD`
- `secrets.KUBECONFIG_DEV`

### File di configurazione repository
- `env/dev/values.env` (o `qa`, `prod` se si cambia argomento di `customize.sh`)
- `properties.env`
- `containers/<service>/platform.conf` (opzionale)

### Parametri indiretti derivati
- Nome repository da `${{ github.event.repository.name }}`.
- SHA commit da `git rev-parse HEAD`.
- Tag immagine per servizio in `imglist`.

## Note operative importanti
1. Il file `imglist` viene creato/appeso da `build_container.sh` e poi letto da `customize.sh`; il job deve mantenere lo stesso workspace tra step.
2. I manifest Kubernetes vengono modificati in-place da `sed -i`.
3. La parte Gateway dipende da:
   - presenza di `endpoint` in `properties.env`
   - esistenza della risorsa `Gateway/nginx-gateway/main-gateway`
   - esistenza del Secret TLS con nome `<token>-secret`