A bela tríade... Github, SonarQube e Quality Gate

É certo que a integração do Sonar com o Quality Gate no fluxo de PRs (Pull Requests) do GitHub representa uma das melhores práticas atuais para garantir a qualidade do código em projetos de desenvolvimento.

Então, aqui, trata-se de configurar o Sonar para analisar cada PR e usar o Quality Gate como critério obrigatório para aprovação do merge.

Seguindo, primeiramente, apresentamos o esquema (figura 1) para um projeto em Python, de forma que o path do arquivo de configuração sonarcloud.yaml seja visualizado. Este arquivo é o componente central da automação, específico para a plataforma GitHub Actions, e localiza-se em .github/workflow.

Optei por passar as configurações necessárias para que o scanner do Sonar (sonar-scanner) saiba como analisar o projeto, como argumentos na ação do sonarcloud-github-actions, ou seja, no sonarcloud.yaml.

Por aqui, o sonarcloud.yaml mostra-se como segue: Ele diz como se dá a automação e como o scanner deve proceder.

name: SonarCloud
on:
pull_request:
  branches:
    - main
    - release/**

jobs:
sonarcloud:
  runs-on: ubuntu-latest
  steps:
  - uses: actions/checkout@v4
    with:
      fetch-depth: 0

  - name: Set up Python
    uses: actions/setup-python@v4
    with:
      python-version: '3.12'

  - name: Install dependencies
    run: |
      python -m pip install --upgrade pip
      if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
      pip install pytest pytest-cov

  - name: Run tests with coverage
    run: |
      python -m pytest --cov=./ --cov-report=xml:coverage.xml --junitxml=test-results.xml tests/ -v

  - name: Verify files
    run: |
      echo "Coverage file:"
      ls -la coverage.xml
      echo "Test results file:"
      ls -la test-results.xml

  - name: SonarCloud Scan
    uses: SonarSource/sonarcloud-github-action@e2a1ee7c31ee491f1e09c74535b1c0d3e9f5cd82
    with:
      args: >
        -Dsonar.python.version=3.12.3
        -Dsonar.projectKey=do_seu
        -Dsonar.projectName=do_seu
        -Dsonar.organization=a_sua
        -Dsonar.projectVersion=1.0
        -Dsonar.sources=.
        -Dsonar.sourceEncoding=UTF-8
        -Dsonar.exclusions=**/tests/**,**/venv/**,**/.venv/**,**/__pycache__/**
        
        -Dsonar.tests=tests
        -Dsonar.python.coverage.reportPaths=coverage.xml
        -Dsonar.python.xunit.reportPath=test-results.xml
        -Dsonar.coverage.exclusions=**/tests/**,**/venv/**,**/.venv/**,**/__pycache__/**
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

Essa automação segue o fluxo que aponta para a release/** ou main (ou master), devido à cobertura do pacote “de graça!” do SonarQube, que não analisa os diferentes tipos de branch, “nada de scanner…”. Então, no caso do caminho feature/** para develop, não haverá análise que será feita em uma PR, cujo fluxo se dá da develop para release/** ou release/** para a main (ou master). É bom usar a main, devido ao humilde plano, caso assim seja, a condição.

E o trabalho? O trabalho é: use o Ubuntu, use o Python, instale as dependências, execute os testes com cobertura maior que 80%, viu… “faça os testes. Se não, não passa nada,” verifique os arquivos, “os resultados…”, e, nessa mesma labuta, para o scanner, use a versão tal do Python, use a chave do projeto e seu nome; essa é a organização. Versione o projeto que está aqui, seja essa a fonte e exclua tudo que não seja útil. Quanto aos saudosos testes, reporte para os arquivos e mande longe o que não é de serventia.

Os tokens? O token do GitHub, em settings – Developer settings – Personal access tokens - Tokens (classic) e o token Sonar, administrado na sua plataforma, My Account – Security, e cadastrado como segredo de repositório no GitHub, settings – General – Secrets and variables – Actions – Repository secrets, “isto não se deixa de fazer!”.

O resto eu me abstenho, tipo o erro quando, por descaso, se deixar a análise automática do Sonar ativa (figura 2); falo mais nada… É linda, diga-se de passagem, a atuação desses caras. Digo, o CI/CD e o scanner.

No mais, é só deixar na ação deles e esperar pelos resultados, “no caso de que venham sempre, satisfeitas as condições e sem muita dor de cabeça.” 😅

Os resultados de um processo automatizado e eficiente, em um código extremamente limpo, zero issues, zero dívida técnica, testes robustos e excelente manutenibilidade, são apresentados nas figuras 3, 4 e 5.

Os mesmos apresentam métricas de cobertura total e em novo código acima do threshold comum de 80%. Mas, embora sejam de zero (0,0%), a métrica de revisados, o resultado sugere que pode ser necessário estabelecer um processo de revisão de segurança.

Nesse belo caso, a conclusão é de que o projeto demonstra práticas excepcionais de qualidade de código, testes de segurança; o Quality Gate aprovado indica que o código está pronto para produção, sem riscos técnicos.

figura 1 - Esquema do projeto

figura 2 - Não siga a recomendação 😁

figura 3 - Resultado da análise em PR

figura 4 - Métricas de qualidade

figura 5 - Cobertura