Download CodeChecker Action - CodeChecker Action Download do código fonte

CodeChecker Action

Outras categorias

v1.0.4

Baixar

Codechecker C ++ Ação de análise estática

Ação do GitHub para executar a análise estática sobre o uso do Codechecker como seu driver. Para projetos de família C (C, C ++, Objective-C, Cuda, etc.), o Codechecker suporta impulsionar os programas de análise estática do CLANG. Vários outros analisadores estáticos de analisadores podem ser integrados ao Codechecker através do conversor do relatório.

Visão geral (para projetos C-Family)

️ CUIDADO! Esta ação foi escrita com comandos que segmentam distribuições baseadas em Ubuntu!

Este script composto de ação única abrange as seguintes etapas:

Obtenha um pacote dos analisadores e Codechecker do LLVM Clang Suite.
(Opcional) registre os comandos de compilação para se preparar para a análise.
Execute a análise.
Mostre a análise resulta no log de CI e crie relatórios HTML que podem ser carregados como um artefato. (O upload deve ser feito pelo usuário!)
(Opcional) Verifique a confirmação atual que introduz novos relatórios de bugs contra um estado conhecido. (Bom para solicitações de tração!)
(Opcional) Carregue os resultados para um servidor Codechecker em execução. (Bom para o projeto principal!)

Nota: A análise estática pode ser um processo demorado. É recomendável que a etapa de análise estática não seja seqüencial com o restante de uma execução de IC, mas seja executada como seu próprio trabalho em um fluxo de trabalho ou um fluxo de trabalho completamente distinto.

Certifique -se de que seu projeto esteja completamente configurado para uma construção antes de executar esta ação.

NOTA: Os analisadores estáticos podem confiar em informações adicionais que são otimizadas em uma verdadeira construção de liberação. Portanto, é recomendável configurar seu projeto em uma configuração Debug .

Especificando o projeto para analisar

Adicione o trabalho ao seu CI da seguinte maneira. As duas versões são mutuamente exclusivas - você pode fornecer um banco de dados de compilação ou instruir o Codechecker a criar um.

Projetos que podem gerar um banco de dados de compilação JSON e construir de maneira limpa (sem código gerado)

Alguns projetos são triviais o suficiente em sua configuração de construção para que nenhuma etapa adicional precisa ser tomada após a execução de configure.sh , cmake ou ferramentas semelhantes. Se você conseguir gerar um banco de dados de compilação do seu sistema de compilação sem executar a própria compilação, poderá economizar algum tempo e ir para a análise imediatamente.

Você pode especificar o banco de dados de compilação gerada na variável logfile

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        logfile : ${{ github.workspace }}/Build/compile_commands.json

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Projetos que precisam criar um banco de dados de compilação JSON ou requer código gerado

Outros tipos de projetos podem depender muito do código gerado . Ao analisar o código -fonte desses projetos sem que uma compilação tenha sido executada com antecedência, eles não compilam - como tal, a análise também não pode ser executada.

Nesse caso, você precisará instruir o Codechecker a registrar uma compilação (e gastar tempo fazendo a construção) pouco antes da análise.

Você pode especificar a compilação para executar na variável build-command .

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Quebrando a construção se houver avisos de análise estática

Se solicitado, a variável de saída de warnings pode ser correspondida contra uma etapa no trabalho que quebra todo o trabalho se algum aviso de análise estática foi emitido pelo projeto.

Nota: Devido à análise estática potencialmente barulhenta e aos relatórios difíceis de corrigir, o comportamento e a recomendação padrão são relatar apenas as descobertas, mas não quebrarem todo o IC.

Para obter os relatórios de uma forma consumível pelo ser humano, eles devem ser carregados em algum lugar primeiro, antes que a etapa de falha falhe todo o trabalho!

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

    # Break the build if there are *ANY* warnings emitted by the analysers.
    - name : " Break build if CodeChecker reported any findings "
      if : ${{ steps.codechecker.outputs.warnings == 'true' }}
      run : exit 1

Enviando resultados para um servidor Codechecker

Se o seu projeto hospedar um servidor Codechecker em algum lugar, o trabalho poderá ser configurado para criar ou atualizar automaticamente uma execução.

 # It is recommended that storing only happens for PUSH events, and preferably
# only for long-term branches.
on :
  push :

job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "
        store : true
        store-url : ' http://example.com:8001/MyProject '
        store-username : ${{ secrets.CODECHECKER_STORE_USER }}
        store-password : ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # store-run-name: "custom run name to store against"

Agindo como um portão de CI em solicitações de puxão

O Codechecker é capaz de calcular a diferença entre duas análises. Se uma análise da versão estável do projeto for armazenada (veja acima) em um servidor, um trabalho para solicitações de tração poderá ser configurado que rejeite automaticamente uma solicitação de tração se tentar introduzir novas descobertas de análise.

Para obter os relatórios de uma forma consumível pelo ser humano, eles devem ser carregados em algum lugar primeiro, antes que a etapa de falha falhe todo o trabalho!

 on :
  pull_request :

runs :
  steps :
    # Check the pull request out! (In pull_request jobs, the checkout action
    # automatically downloads the "after-merge" state of the pull request if
    # there are no conflicts.)
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

        store : ${{ github.event_name == 'push' }}
        store-url : ' http://example.com:8001/MyProject '
        store-username : ${{ secrets.CODECHECKER_STORE_USER }}
        store-password : ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # Keep the names for 'store' and 'diff' in sync, or auto-generated!
        # diff-run-name: "custom run name to store with"

        diff : ${{ github.event_name == 'pull_request' }}
        diff-url : ' http://example.com:8001/MyProject '
        diff-username : ${{ secrets.CODECHECKER_DIFF_USER }}
        diff-password : ${{ secrets.CODECHECKER_DIFF_PASSWORD }}
        # diff-run-name: "custom run name to diff against"

    # Upload the potential new findings results to the CI.
    - uses : actions/upload-artifact@v2
      if : ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      with :
        name : " New introduced results Bug Reports "
        path : ${{ steps.codechecker.outputs.diff-html-dir }}

    - name : " Fail the job if new findings are introduced "
      if : ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      shell : bash
      run : |
        echo "::error title=New static analysis warnings::Analysed commit would introduce new static analysis warnings and potential bugs to the project"
        # Fail the build, after results were collected and uploaded.
        exit 1

Visão geral (para outras análises através do contador de relatórios )

️ CUIDADO! Esta ação foi escrita com comandos que segmentam distribuições baseadas em Ubuntu!

Este script composto de ação única abrange as seguintes etapas:

Obtenha um pacote de Codechecker.
Use o report-converter para converter os relatórios de outros analisadores no formato do Codechecker.
Mostre a análise resulta no log de CI e crie relatórios HTML que podem ser carregados como um artefato. (O upload deve ser feito pelo usuário!)
(Opcional) Verifique a confirmação atual que introduz novos relatórios de bugs contra um estado conhecido. (Bom para solicitações de tração!)
(Opcional) Carregue os resultados para um servidor Codechecker em execução. (Bom para o projeto principal!)

Nota: A análise estática pode ser um processo demorado. É recomendável que a etapa de análise estática não seja seqüencial com o restante de uma execução de IC, mas seja executada como seu próprio trabalho em um fluxo de trabalho ou um fluxo de trabalho completamente distinto.

Consulte a documentação do analisador de sua escolha para isso. O Codechecker não suporta impulsionar a análise por meio de ferramentas externas, mas se uma análise bem -sucedida foi realizada, ela pode converter e armazenar os resultados.

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Perform the analysis. Details vary between analysers!
    # Example for "PyLint" added below!
    - name : " Analyse with PyLint "
      run : |
        sudo apt-get -y install pylint
        pylint -f json --exit-zero myproject > pylint_reports.json

    # Run the conversion
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        report-converter : true
        original-analyser : " pylint "
        original-analysis-output : " pylint_reports.json "

    # Upload the results (after conversion by CodeChecker) to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Enviando resultados e atuando como um portão CI

A ferramenta Relatório conversora converte a saída de vários analisadores no formato comum usado pelo Codechecker. Depois que a conversão é feita, o restante dos recursos da ação pode ser executado da mesma maneira que para os projetos C/C ++. Consulte as partes anteriores da documentação para a configuração desses recursos.

Configuração de ação

Variável	Padrão	Descrição
`config`	`$(project-root)/.codechecker.json`	O arquivo de configuração que contém sinalizadores a serem anexados aos comandos de análise. Recomenda -se que a maior parte da configuração de análise seja versão do projeto. ? Leia mais sobre o arquivo de configuração `codechecker.json` na documentação oficial.

Versões para instalar

Variável	Padrão	Descrição
`llvm-version`	`latest`	A versão principal do LLVM para instalar e usar. O LLVM está instalado no PPA da comunidade. O valor deve ser uma versão principal (por exemplo, `13` ) suportada pelo PPA para o sistema operacional usado! Se `latest` , colete automaticamente a versão mais recente (ainda não lançada). Se `ignore` , não instale nada. (Não recomendado.)
`install-custom`	`false`	Se definido como `true` , abre a capacidade de clonar localmente e instalar o Codechecker no `repository` e `version` especificados. Caso contrário, `version` é tomada como uma versão de liberação e a suíte Codechecker da Pypi é baixada.
`repository`	`Ericsson/CodeChecker`	O repositório Codechecker para verificar e construir, se `install-custom` for `true` .
`version`	`master`	Se `install-custom` for `false` , a versão de liberação (por exemplo, `6.18.0` ) para baixar do Pypi ou `master` para obter a versão mais recente. Caso contrário, a filial (inadimplente para `master` ), marcar ou comprometer o SHA no `repository` para verificar.

Construir configuração de log

? Leia mais sobre o CodeChecker log na documentação oficial.

Variável	Padrão	Descrição
`logfile`		A localização do banco de dados de compilação JSON que descreve como o projeto é criado. Esse sinalizador é usado se o sistema de compilação puder pré-generalizar o arquivo para nós.
`build-command`		O comando de construção para executar. O Codechecker é capaz de executar e registrar a construção por si mesma. Esse sinalizador é usado se o sistema de construção não puder gerar as informações por si só, ou o projeto depende de outro código gerado.

Configuração de análise

? Leia mais sobre CodeChecker analyze na documentação oficial.

Variável	Padrão	Descrição
`analyze-output`	(gerado automaticamente)	O diretório em que a saída de análise bruta deve ser armazenada.
`ctu`	`false`	Ativar análise de unidade de tradução cruzada no analisador estático de Clang . ️ CUIDADO! A análise da CTU pode levar muito tempo e a CTU é oficialmente considerada experimental.
`ignore-analyze-crashes`	`true`	Se definido como `true` , a fase de análise não relatará um erro se algumas ações de análise falharem (devido a possíveis falhas em Clang).

Configuração do relatório

? Leia mais sobre a CodeChecker parse na documentação oficial.

Relatório Configuração de conversão

? Leia mais sobre o report-converter na documentação oficial.

Variável	Padrão	Descrição
`report-converter`	`false`	Se definido como `true` , o trabalho executará a conversão do relatório de outros analisadores, em vez de impulsionar a análise estática por si só.
`original-analyser`		O "tipo" da análise que havia sido realizada anteriormente. Passado como entrada obrigatória para o executável `report-converter` .
`original-analysis-output`		O arquivo ou diretório em que os resultados do analisador de terceiros estão disponíveis. Passado como entrada obrigatória para o executável `report-converter` .

Configuração diff

? Leia mais sobre CodeChecker cmd diff na documentação oficial.

? Verificando os resultados da análise em relação ao conteúdo de um servidor requer a permissão PRODUCT_VIEW , se o servidor estiver exigindo autenticação.

Variável	Padrão	Descrição
`diff`	`false`	Se definido como `true` , o trabalho calculará um diff dos resultados da análise atual em relação aos resultados armazenados em um servidor remoto.
`diff-url`		O URL do produto Codechecker para verificar e diferenciar, incluindo o terminal. Geralmente no formato de `http://example.com/ProductName` . Especificando essa variável é necessária se `diff` foi definido como `true` .
`diff-username`		Se o servidor precisar de autenticação para acessar, especifique o nome de usuário com o qual a verificação deve fazer login.
`diff-password`		A senha ou o token de acesso gerado correspondente ao usuário. ? Nota: Recomenda -se que isso seja configurado como um segredo do repositório e dado como tal: `${{ secrets.CODECHECKER_PASSWORD }}` ao configurar a ação.
`diff-run-name`	(gerado automaticamente, no Format `user/repo: branchname` )	As execuções de análise Codechecker são coletadas em execuções . Uma execução geralmente se correlaciona com uma configuração da análise.

Armazenar configuração

? Leia mais sobre CodeChecker store na documentação oficial.

? O armazenamento de execução em um servidor requer a permissão PRODUCT_STORE , se o servidor estiver exigindo autenticação.

Variável	Padrão	Descrição
`store`	`false`	Se definido como `true` , o script fará o upload das descobertas para um servidor Codechecker. Geralmente, outras bandeiras também precisam ser configuradas!
`store-url`		O URL do produto Codechecker para armazenar, incluindo o terminal. Geralmente no formato de `http://example.com/ProductName` . Especificando essa variável é necessária se `store` foi definida como `true` .
`store-username`		Se o servidor exigir a autenticação para acessar, especifique o nome de usuário com o qual o upload deve fazer login.
`store-password`		A senha ou o token de acesso gerado correspondente ao usuário. ? Nota: Recomenda -se que isso seja configurado como um segredo do repositório e dado como tal: `${{ secrets.CODECHECKER_PASSWORD }}` ao configurar a ação.
`store-run-name`	(gerado automaticamente, no Format `user/repo: branchname` )	As execuções de análise Codechecker são coletadas em execuções . Uma execução geralmente se correlaciona com uma configuração da análise. As execuções podem ser armazenadas de forma incremental; nesse caso, o Codechecker pode anotar que os relatórios foram corrigidos.

`outputs` de ação a serem usadas em outras etapas

A ação expõe as seguintes saídas que podem ser usadas nas etapas de um fluxo de trabalho, sucedendo a análise.

Variável	Valor	Descrição
`analyze-output`	Entrada gerada automaticamente ou `analyze-output`	O diretório em que os arquivos de saída de análise bruta (criados pelos analisadores ou pelo conversor) estão disponíveis.
`codechecker-version`	Gerado automaticamente (provavelmente o mesmo que `version` de entrada)	A versão do Codechecker instalado que executou a análise.
`codechecker-hash`	Gerado automaticamente.	O hash git do Codechecker instalado que executou a análise.
`logfile`	Entrada gerada automaticamente ou `logfile`	O banco de dados de compilação JSON da análise que foi executado.
`llvm-version`	Gerado automaticamente.	A string de versão completa do pacote LLVM/CLANG instalado (conforme relatado por `clang --version` ).
`diff-html-dir`	Gerado automaticamente.	O diretório em que os relatórios de bugs HTML amigáveis foram gerados para as novas descobertas (se `diff` estivesse ativado).
`diff-result-log`	Gerado automaticamente.	O arquivo de log de saída `CodeChecker cmd diff` , que contém as novas descobertas despejadas nele.
`diff-run-name`	Entrada gerada automaticamente ou `diff-run-name`	O nome da análise da análise (se `diff` foi ativado) contra o qual os relatórios foram comparados.
`result-html-dir`	Gerado automaticamente.	O diretório em que os relatórios de bugs HTML fáceis de usar foram gerados.
`result-log`	Gerado automaticamente.	O arquivo de log de saída `CodeChecker parse` , que contém as descobertas despejadas nele.
`store-run-name`	Entrada gerada automaticamente ou `store-run-name`	O nome da análise da análise (se `store` foi ativada) para a qual os resultados foram enviados.
`store-successful`	`true` ou `false`	Se armazenando os resultados foram bem -sucedidos. Útil para quebrar opcionalmente a construção posteriormente para detectar falhas de rede.
`warnings`	`true` ou `false`	Se os analisadores estáticos relataram algum achado.
`warnings-in-diff`	`true` ou `false`	Se `diff` foi ativado, se houve novas descobertas na análise atual quando comparadas com o conteúdo do servidor.