Pipeline de Aplicação¶

O pipeline de aplicação (ads-automations) centraliza toda a automação de CI/CD das aplicações. Todo repositório de aplicação consome os workflows e actions deste repositório via workflow_call.

A arquitetura do pipeline utiliza várias ferramentas de qualidade, segurança e automação para garantir que o código seja testado, verificado e implantado de forma confiável e eficiente.

Figura 1: Pipeline de Aplicação

×

Visão Geral¶

flowchart LR
    A[Branch] --> B[Pull Request]
    B --> C{Evento}
    C -->|opened/sync| D[PR Pipeline]
    C -->|merged| E[Merge Pipeline]
    C -->|tag v*| F[Deploy Tag]

    D --> D1[Gemini Review]
    D --> D2[Jira Validation]
    D --> D3[Build + Test + Sonar]
    D --> D4[Docker Push<br/>sprint-PR-123]

    E --> E1[Jira Validation]
    E --> E2[Semantic Tag<br/>v8.0.0]
    E --> E3[Build + Docker Push]
    E --> E4[Update HML Tenants]
    E --> E5[Jira → Aguardando Teste]

    F --> F3[Build + Docker Push]

Como Funciona¶

Cada repositório de aplicação possui uma cópia do template application-pipeline.yml no seu .github/workflows/. Este template:

1. Detecta a linguagem — lê o Dockerfile da aplicação para identificar java ou node e a versão
2. Despacha para o workflow correto conforme o evento do GitHub:

PR Pipeline¶

Executado em toda atualização de PR. Realiza revisão automática, validação e build.

Jobs¶

1. Gemini AI Code Review (pr-summarize)¶

O pipeline envia o diff do PR para a API do Google Gemini (gemini-2.0-flash) que gera uma revisão estruturada:

• Resumo das alterações
• Análise técnica
• Pontos positivos
• Problemas encontrados
• Sugestões de melhoria

O resultado é postado como comentário sticky no PR com header gemini-code-review.

2. Jira Validation¶

Valida que o PR está associado a um ticket Jira. O ID é extraído de (em ordem de prioridade):

1. Título do PR
2. Nome da branch
3. Mensagens de commit

Formato esperado: [A-Z]+-[0-9]+ (ex: PROJ-123)

Além de validar o ticket, extrai o Sprint ID (ex: 8.0.0) que será usado no versionamento.

3. Build + Test + SonarQube¶

Dependendo da linguagem detectada, executa o pipeline Java ou Node:

4. Docker Build + Push¶

Builda a imagem Docker e pusha para o OCIR com tag {sprint}-PR-{pr_number}:

gru.ocir.io/grbtf2fwsmfh/{app}:{sprint}-PR-{pr_number}

Merge Pipeline¶

Executado quando um PR é merge. Calcula versão semântica, rebuilda, e atualiza tenants HML.

Jobs¶

1. Versionamento Semântico (calculate-and-tag)¶

O sistema de versionamento é baseado no Sprint do Jira:

O workflow cria a tag git e a pusha automaticamente.

2. Cleanup da Imagem PR¶

Após o merge, a imagem de PR ({sprint}-PR-{pr_number}) é deletada do OCIR via action delete-ocir-image-tag.

3. Build + Docker Push¶

Rebuilda e pusha com a tag semântica calculada (ex: v8.0.0).

4. Atualização de Tenants HML¶

Apenas em merges para development: dispara repository_dispatch no repositório ads-automations que executa update-hml-tenants.yml:

1. Extrai token do bot
2. Clona ads-tenants-config
3. Atualiza image.tag nos values.yaml de todos os tenants HML
4. Commit e push para main
5. Comenta no PR de origem com detalhes da atualização

5. Transição Jira¶

Move o ticket Jira para o status "Aguardando Teste" após atualização bem-sucedida dos tenants.

Deploy Tag Pipeline¶

Pipeline simplificado para builds a partir de tags manuais (v*). Apenas roteia para o pipeline Java ou Node baseado na linguagem detectada, sem validação Jira ou atualização de tenants.

Usado para:

• Rebuilds de versões específicas
• Hotfixes que precisam de tag manual

Workflows Disponíveis¶

Actions Disponíveis¶

Secrets e Configuração¶

Todos os workflows dependem de dois secrets do repositório:

• PIPELINE_SECRETS: JSON contendo todas as credenciais (OCIR, Jira, SonarQube, OCI CLI, AWS)
• TOKEN: GitHub token com permissões cross-repo

A action setup-environment parseia o JSON e exporta cada credencial como variável de ambiente mascarada.

Runners¶