Workflows Reutilizáveis

A GTI disponibiliza pipelines padronizadas no formato de Reusable Workflows (workflow_call). Elas centralizam boas práticas de compilação de imagens, varredura de segurança contra vulnerabilidades (Trivy) e publicação contínua (GitOps/Kustomize) para a infraestrutura da CODATA.

---

1. build-and-push

Pipeline de integração contínua responsável pela compilação conteinerizada via Buildah, sanitização de nomenclaturas, envio para o Registry institucional, inspeção estrita de segurança e atualização opcional do ambiente de homologação (hml).

Entradas (inputs)

Parâmetro	Tipo	Obrigatório	Padrão	Descrição
dockerfile	string	Não	./Dockerfile	Caminho relativo do arquivo de receita da imagem.
context	string	Não	.	Diretório de contexto para execução do build.

Segredos e Variáveis Requeridos

• Secrets:
  • REGISTRY_TOKEN: Token com permissão de escrita no Container Registry do GitSES.
  • GITCODATA_REPO (condicional): URL do repositório GitOps da CODATA.
  • GITCODATA_USERNAME (condicional): Usuário de serviço com permissão no repositório GitOps.
  • GITCODATA_TOKEN (condicional): Token de acesso com permissão de push no repositório GitOps.
• Variables:
  • DEPLOY_CODATA: Defina com o valor 1 para habilitar a execução da etapa de deploy em homologação.

Etapas do Pipeline (jobs)

1. build:
   • Executa no runner sob a label docker.
   • Realiza o checkout do repositório.
   • Executa a sanitização dos identificadores da imagem, tags e versão do pacote via actions dedicadas.
   • Compila a imagem usando actions/buildah-build@v2 com base no dockerfile e context fornecidos.
   • Exporta variáveis de saída (outputs): registry_url, repo_owner, image_name e tag.
   • Envia a imagem final para o Registry via actions/push-to-registry@v2.
2. security-scan:
   • Depende da conclusão bem-sucedida do job build.
   • Restaura o cache local da base do Trivy (.trivycache/).
   • Analisa a imagem recém-enviada contra vulnerabilidades, falhas de configuração e segredos expostos (scanners: vuln,misconfig,secret).
   • Interrompe a esteira com erro (exit-code: 1) se encontrar severidades MEDIUM, HIGH ou CRITICAL.
3. deploy-codata (Homologação):
   • Condicionado a vars.DEPLOY_CODATA == 1 e ao término com sucesso dos jobs build e security-scan.
   • Aciona actions/gitcodata-kustomize-update@v1 apontando para o ambiente hml no repositório GitOps informado.

Como executar

Em seu repositório, crie o arquivo .forgejo/workflows/build-and-push.yaml com o seguinte conteúdo:

name: Build a Container Image and push to Registry

on:
  push:
    tags:
      - 'v*'

jobs:
  build-and-push:
    uses: actions/reusable-workflows/.forgejo/workflows/build-and-push.yaml@main
    secrets: inherit

---

2. deploy-codata-prd

Pipeline voltada para implantação em produção (prd). É utilizada para promover uma versão/tag já existente no Registry, executando a validação de segurança do Trivy antes de aplicar a alteração no repositório GitOps.

Segredos e Variáveis Requeridos

• Secrets:
  • REGISTRY_TOKEN: Token para autenticação e inspeção da imagem no Registry.
  • GITCODATA_REPO: URL do repositório GitOps da CODATA.
  • GITCODATA_USERNAME: Usuário de serviço com permissão no repositório GitOps.
  • GITCODATA_TOKEN: Token de acesso com permissão de escrita no repositório GitOps.

Etapas do Pipeline (jobs)

1. image-data:
   • Sanitiza e padroniza os dados do registro, proprietário, versão e nome da imagem a partir do contexto da execução.
   • Exporta as saídas (outputs) necessárias para os jobs subsequentes.
2. security-scan:
   • Depende da resolução do job image-data.
   • Bloqueia a execução (exit-code: 1) caso existam vulnerabilidades classificadas como MEDIUM, HIGH ou CRITICAL.
3. deploy-codata (Produção):
   • Condicionado ao término com sucesso dos jobs image-data e security-scan (declarado internamente como trivy-scan).
   • Aciona actions/gitcodata-kustomize-update@v1 configurado para o ambiente prd.

Como executar

1. Em seu repositório, crie o arquivo .forgejo/workflows/deploy-codata-prd.yaml com o seguinte conteúdo:

   name: Deploy Image to Codata PRD
   
   on:
     workflow_dispatch:
   
   jobs:
     deploy-codata-prd:
       uses: actions/reusable-workflows/.forgejo/workflows/deploy-codata-prd.yaml@main
       secrets: inherit

2. Em repositório > Acões selecione o workflow no menu lateral, clique em Executar workflow e especifique a tag desejada

---

3. Políticas de Execução e Segurança

• Obrigatoriedade Institucional de Deploy: Qualquer deploy, atualização ou publicação de sistemas e serviços executados na infraestrutura da SES-PB (ou parceira, como a CODATA) deve passar obrigatoriamente por essas pipelines institucionais. É estritamente vedado qualquer processo de publicação manual, build local não auditado ou deploy direto fora das esteiras homologadas da GTI.

• Critério de Bloqueio por Vulnerabilidades: Ambas as esteiras bloqueiam qualquer publicação caso o Trivy aponte vulnerabilidades ativas a partir do nível médio (MEDIUM).

• Segregação de Permissões: O deploy para infraestrutura externa (CODATA) é isolado por condicionais de variáveis de ambiente (DEPLOY_CODATA), impedindo execuções automáticas não autorizadas.