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: Em qualquer branch (configuração atual on: [push]).

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):

Checkout
- Utiliza actions/checkout@v3 para clonar o código fonte do repositório.
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.
Build e Push
- Constrói a imagem Docker da aplicação.
- Tags geradas:
  - 172.35.0.216/library/vendaweb-api:$TAG (onde $TAG é o SHA do commit do Gitea gitea.sha)
  - 172.35.0.216/library/vendaweb-api:latest
- Envia ambas as tags para o registry.

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).

2.3 KiB Raw Blame History