# Documentação dos Workflows (Gitea Actions)

Este documento descreve os fluxos de trabalho de integração contínua (CI) e entrega contínua (CD) configurados no Gitea Actions para o projeto **Vendaweb-api**.

## Visão Geral

Os workflows estão definidos no diretório `.gitea/workflows/`. O principal workflow configurado é o deploy da API.

## Workflow: Deploy NestJS API

**Arquivo**: `.gitea/workflows/deploy-api.yaml`

### Gatilhos (Triggers)

Este workflow é acionado automaticamente no evento:

- `push`: Na branch `main`.

### Jobs

#### `build-and-push-deploy`

Este job é responsável por construir a imagem Docker e enviá-la para o registry privado (Harbor).

- **Ambiente de Execução**: `ubuntu-latest` (Runner)

#### Passos (Steps):

1. **Checkout**
   - Utiliza `actions/checkout@v3` para clonar o código fonte do repositório.

2. **Login no Harbor**
   - Realiza autenticação no registry Docker privado.
   - **Registry**: `172.35.0.216`
   - **Segredos Utilizados**:
     - `HARBOR_USERNAME`: Nome de usuário do Harbor.
     - `HARBOR_PASSWORD`: Senha do usuário do Harbor.

3. **Build e Push**
   - Constrói a imagem Docker da aplicação.
   - Tags geradas:
     - `git.simplifiquehc.com.br/simplifique/vendaweb-api:$TAG` (onde `$TAG` é o SHA curto do commit)
     - `git.simplifiquehc.com.br/simplifique/vendaweb-api:latest`
   - Envia ambas as tags para o registry.

4. **Atualizar Manifest e Push no Git**
   - Atualiza `k8s/overlays/prod/deployment-image-digest-patch.yaml` para apontar para a tag `$TAG`.

## Variáveis e Segredos (Secrets)

Para que o workflow funcione corretamente, as seguintes secrets devem estar configuradas nas configurações do repositório no Gitea:

| Secret            | Descrição                                                     |
| ----------------- | ------------------------------------------------------------- |
| `HARBOR_USERNAME` | Usuário com permissão de push no projeto `library` do Harbor. |
| `HARBOR_PASSWORD` | Senha ou token de acesso do usuário do Harbor.                |

## Integração com Kubernetes

Após o push da imagem com a tag `latest` (e o SHA específico), o ArgoCD (configurado conforme `KUBERNETES.md`) detectará as mudanças se houver alteração nos manifestos ou se estiver configurado para pollar a imagem `latest` (dependendo da política de `imagePullPolicy` e configuração do ArgoCD Image Updater, se houver).