CodeChecker Action Download - CodeChecker Action Quellcode Download

CodeChecker Action

Andere Kategorien

v1.0.4

Herunterladen

Codechecker C ++ statische Analyseaktion

GitHub -Aktion zur Durchführung einer statischen Analyse über die Verwendung von CodeChecker als Treiber. Für C-Familienprojekte (C, C ++, Objective-C, CUDA usw.) unterstützt Codechecker die statischen Analyseprogramme von Clang. Mehrere andere statische Analysatorenausgaben können über den Berichtskonverter in CodeCecher integriert werden.

Übersicht (für C-Familienprojekte)

Euen VORSICHT! Diese Aktion wurde mit Befehlen geschrieben, die auf Ubuntu-basierte Verteilungen abzielen!

Dieses Skript für ein einzelne Aktion umfasst die folgenden Schritte:

Erhalten Sie ein Paket der Analysatoren der LLVM Clang Suite und Codechecker.
(Optional) Loggen Sie die Build -Befehle an, um sich auf die Analyse vorzubereiten.
Führen Sie die Analyse aus.
Zeigen Sie die Analyseergebnisse im CI -Protokoll und erstellen Sie HTML -Berichte, die als Artefakt hochgeladen werden können. (Das Hochladen ist vom Benutzer zu erfolgen!)
(Optional) Überprüfen Sie, ob das aktuelle Commit neue Fehlerberichte gegen einen bekannten Staat einführen. (Gut für Zuganfragen!)
(Optional) Laden Sie die Ergebnisse auf einen laufenden Codechecker -Server hoch. (Gut für das Hauptprojekt!)

Hinweis: Die statische Analyse kann ein zeitaufwändiger Prozess sein. Es wird empfohlen, dass der statische Analyseschritt nicht mit dem Rest einer CI -Ausführung sequentiell ist, sondern entweder als eigener Auftrag in einem Workflow oder in einem völlig unterschiedlichen Workflow ausgeführt wird.

Bitte stellen Sie sicher, dass Ihr Projekt vor der Ausführung dieser Aktion vollständig für einen Build konfiguriert ist.

Hinweis: Statische Analysatoren können sich auf zusätzliche Informationen verlassen, die in einem echten Release -Build optimiert werden. Daher wird empfohlen, Ihr Projekt in einer Debug -Konfiguration zu konfigurieren.

Analyse des analysierenden Projekts

Fügen Sie den Job wie folgt in Ihre CI hinzu. Die beiden Versionen schließen sich gegenseitig aus - Sie können entweder eine Kompilierungsdatenbank angeben oder Codechecker anweisen, eine zu erstellen.

Projekte, die eine JSON -Kompilierungsdatenbank generieren und sauber erstellen können (kein generierter Code)

Einige Projekte sind in ihrer Build -Konfiguration trivial genug, damit nach der Ausführung configure.sh , cmake oder ähnlichen Tools keine zusätzlichen Schritte unternommen werden müssen. Wenn Sie in der Lage sind, eine Kompilierungsdatenbank aus Ihrem Build -System zu generieren, ohne den Build selbst auszuführen, können Sie einige Zeit sparen und sofort zur Analyse wechseln.

Sie können die generierte Kompilierungsdatenbank in der logfile -Variable angeben

 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 }}

Projekte, die eine JSON-Kompilierungsdatenbank selbst erstellen müssen oder generierten Code erfordern

Andere Arten von Projekten können sich stark auf generierten Code verlassen. Wenn Sie sich den Quellcode dieser Projekte ansehen, ohne dass zuvor ein Build ausgeführt wurde, werden sie nicht kompiliert - als solche kann auch die Analyse nicht durchgeführt werden.

In diesem Fall müssen Sie Codechecker anweisen, kurz vor der Analyse einen Build zu protokollieren (und Zeit mit dem Aufbau zu verbringen).

Sie können den Build angeben, der in der Variablen build-command Variable ausgeführt werden soll.

 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 }}

Brechen des Builds, wenn es statische Analysewarnungen gibt

Auf Wunsch kann die warnings angepasst werden, um einen Schritt in dem Job auszuführen, der den gesamten Job durchbricht, wenn die statischen Analysewarnungen vom Projekt abgeliefert wurden.

HINWEIS: Da die statische Analyse potenziell laut ist und die Berichte unhandlich sind, um zu beheben, besteht das Standardverhalten und die Empfehlung darin, nur die Ergebnisse zu melden, aber nicht die gesamte CI zu brechen.

Um die Berichte in menschlich verzehrbarer Form zu erhalten, müssen sie zuerst irgendwo hochgeladen werden, bevor der Fehlerschritt den gesamten Job fehlschlägt!

 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

Das Hochladen von Ergebnissen auf einen Codechecker -Server

Wenn Ihr Projekt irgendwo einen Codechecker -Server hostet, kann der Job so konfiguriert werden, dass er automatisch einen Lauf erstellt oder aktualisiert.

 # 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"

Als CI -Tor bei Pull -Anfragen fungieren

Codechecker kann die Differenz zwischen zwei Analysen berechnen. Wenn eine Analyse der stabilen Version des Projekts (siehe oben) auf einen Server gespeichert wird, kann ein Auftrag für Pull -Anforderungen konfiguriert werden, der automatisch eine Pull -Anforderung ablehnt, wenn sie versucht, neue Analyseergebnisse einzuführen.

Um die Berichte in menschlich verzehrbarer Form zu erhalten, müssen sie zuerst irgendwo hochgeladen werden, bevor der Fehlerschritt den gesamten Job fehlschlägt!

 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

Übersicht (für andere Analysen über den Berichtskonverter )

Euen VORSICHT! Diese Aktion wurde mit Befehlen geschrieben, die auf Ubuntu-basierte Verteilungen abzielen!

Dieses Skript für ein einzelne Aktion umfasst die folgenden Schritte:

Erhalten Sie ein Paket Codechecker.
Verwenden Sie den report-converter um die Berichte anderer Analysatoren in das Format von Codecheckers umzuwandeln.
Zeigen Sie die Analyseergebnisse im CI -Protokoll und erstellen Sie HTML -Berichte, die als Artefakt hochgeladen werden können. (Das Hochladen ist vom Benutzer zu erfolgen!)
(Optional) Überprüfen Sie, ob das aktuelle Commit neue Fehlerberichte gegen einen bekannten Staat einführen. (Gut für Zuganfragen!)
(Optional) Laden Sie die Ergebnisse auf einen laufenden Codechecker -Server hoch. (Gut für das Hauptprojekt!)

Hinweis: Die statische Analyse kann ein zeitaufwändiger Prozess sein. Es wird empfohlen, dass der statische Analyseschritt nicht mit dem Rest einer CI -Ausführung sequentiell ist, sondern entweder als eigener Auftrag in einem Workflow oder in einem völlig unterschiedlichen Workflow ausgeführt wird.

Weitere Informationen finden Sie in der Dokumentation des Analysators Ihrer Wahl dafür. Codechecker unterstützt nicht , die Analyse durch externe Tools zu fördern. Wenn jedoch eine erfolgreiche Analyse durchgeführt wurde, kann sie die Ergebnisse konvertieren und speichern.

 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 }}

Ergebnisse hochladen und als CI -Tor fungieren

Das Berichtskonverter- Tool wandelt die Ausgabe verschiedener Analysatoren in das von Codechecker verwendete gemeinsame Format um. Sobald die Konvertierung abgeschlossen ist, können die restlichen Funktionen der Aktion auf die gleiche Weise wie für C/C ++ - Projekte ausgeführt werden. In früheren Teilen der Dokumentation finden Sie die Konfiguration dieser Funktionen.

Aktionskonfiguration

Variable	Standard	Beschreibung
`config`	`$(project-root)/.codechecker.json`	Die Konfigurationsdatei, die Flags enthält, die an die Analysebefehle angehängt werden sollen. Es wird empfohlen, dass der größte Teil der Analysekonfiguration mit dem Projekt versioniert wird. ? Lesen Sie mehr über die Konfigurationsdatei `codechecker.json` in der offiziellen Dokumentation.

Versionen zu installieren

Variable	Standard	Beschreibung
`llvm-version`	`latest`	Die Hauptversion von LLVM zu installieren und zu verwenden. LLVM ist von der Community PPA installiert. Der Wert muss eine Hauptversion (z. B. `13` ) sein, die vom PPA für das verwendete Betriebssystem unterstützt wird! Wenn `latest` die neueste (noch unveröffentlichte) Version sammeln. Wenn `ignore` , installieren Sie nichts. (Nicht empfohlen.)
`install-custom`	`false`	Wenn Sie auf `true` gesetzt sind, öffnen Sie die Möglichkeit, CodeCecher aus dem angegebenen `repository` und `version` lokal zu klonen und zu installieren. Andernfalls wird `version` als Release -Version genommen, und die CodeCecher -Suite von PYPI wird heruntergeladen.
`repository`	`Ericsson/CodeChecker`	Das Codechecker-Repository zum Auschecken und Erstellen, wenn `install-custom` `true` ist.
`version`	`master`	Wenn `install-custom` `false` ist, wird die Release-Version (z. B. `6.18.0` ) von PYPI heruntergeladen oder `master` , um die neueste Version abzurufen. Andernfalls ist der Zweig (auf `master` ), Tag oder begehen SHA im `repository` zum Auschecken.

Protokollkonfiguration erstellen

? Lesen Sie mehr über CodeChecker log in der offiziellen Dokumentation.

Variable	Standard	Beschreibung
`logfile`		Der Ort der JSON -Kompilierungsdatenbank, in der beschreibt, wie das Projekt erstellt wird. Dieses Flag wird verwendet, wenn das Build-System die Datei für uns vor generieren kann.
`build-command`		Der Befehl Build, um auszuführen. Codechecker ist in der Lage, den Build für sich selbst auszuführen und zu protokollieren. Dieses Flag wird verwendet, wenn das Build-System die Informationen nicht selbst generieren kann oder das Projekt auf anderen generierten Code beruht.

Analysekonfiguration

? Lesen Sie mehr über CodeChecker analyze in der offiziellen Dokumentation.

Variable	Standard	Beschreibung
`analyze-output`	(automatisch generiert)	Das Verzeichnis, in dem die RAW -Analyseausgabe gespeichert werden sollte.
`ctu`	`false`	Aktivieren Sie die Analyse der Cross Translation Unit im Clang Static Analyzer . Euen VORSICHT! Die CTU -Analyse kann sehr lange dauern, und die CTU wird offiziell als experimentell angesehen.
`ignore-analyze-crashes`	`true`	Wenn auf `true` festgelegt wird, meldet die Analysephase keinen Fehler, wenn einige Analyseaktionen fehlschlagen (aufgrund potenzieller Abstürze in Clang).

Berichtskonfiguration

? Lesen Sie mehr über CodeChecker parse in der offiziellen Dokumentation.

Konfiguration der Konvertierung melden

? Lesen Sie mehr über den report-converter in der offiziellen Dokumentation.

Variable	Standard	Beschreibung
`report-converter`	`false`	Wenn der Auftrag auf `true` gesetzt ist, führt der Job die Konvertierung von Bericht von anderen Analysatoren durch, anstatt die statische Analyse selbst zu steuern.
`original-analyser`		Der "Typ" der Analyse, der zuvor durchgeführt worden war . Als obligatorische Eingabe in den ausführbaren `report-converter` übergeben.
`original-analysis-output`		Die Datei oder das Verzeichnis, in dem die Ergebnisse des Drittanalysators verfügbar sind. Als obligatorische Eingabe in den ausführbaren `report-converter` übergeben.

Diff -Konfiguration

? Lesen Sie mehr über CodeChecker cmd diff in der offiziellen Dokumentation.

? Durch die Überprüfung der Analyseergebnisse mit dem Inhalt eines Servers erfordert die PRODUCT_VIEW -Berechtigung, wenn der Server eine Authentifizierung benötigt.

Variable	Standard	Beschreibung
`diff`	`false`	Wenn der Job auf `true` eingestellt ist, berechnet der Job einen Diff der aktuellen Analyseergebnisse mit den auf einem Remote -Server gespeicherten Ergebnissen.
`diff-url`		Die URL des Codechecker -Produkts zum Überprüfen und Differenzieren, einschließlich des Endpunkts. Normalerweise im Format von `http://example.com/ProductName` . Das Angeben dieser Variablen ist erforderlich , wenn `diff` auf `true` eingestellt wurde.
`diff-username`		Wenn der Server eine Authentifizierung benötigt, um zugreifen zu können, geben Sie den Benutzernamen an, mit dem sich die Prüfung anmelden soll.
`diff-password`		Das Passwort oder generierte Zugriffstoken entspricht dem Benutzer. ? HINWEIS: Es wird empfohlen, dass dies als Repository -Geheimnis konfiguriert und als solche angegeben ist: `${{ secrets.CODECHECKER_PASSWORD }}` beim Konfigurieren der Aktion.
`diff-run-name`	(automatisch generiert, im Format `user/repo: branchname` )	Codechecker -Analyse -Ausführungen werden in Läufe gesammelt. Ein Lauf korreliert normalerweise mit einer Konfiguration der Analyse.

Konfiguration speichern

? Lesen Sie mehr über CodeChecker store in der offiziellen Dokumentation.

? Das Speichern von Läufen auf einen Server erfordert die PRODUCT_STORE -Berechtigung, wenn der Server eine Authentifizierung benötigt.

Variable	Standard	Beschreibung
`store`	`false`	Wenn auf `true` festgelegt wird, lädt das Skript die Ergebnisse auf einen Codechecker -Server hoch. Normalerweise müssen auch andere Flags konfiguriert werden!
`store-url`		Die URL des Codechecker -Produkts zum Speichern, einschließlich des Endpunkts. Normalerweise im Format von `http://example.com/ProductName` . Das Angeben dieser Variablen ist erforderlich , wenn `store` auf `true` eingestellt wurde.
`store-username`		Wenn der Server eine Authentifizierung benötigt, um zugreifen zu können, geben Sie den Benutzernamen an, mit dem sich das Upload anmelden soll.
`store-password`		Das Passwort oder generierte Zugriffstoken entspricht dem Benutzer. ? HINWEIS: Es wird empfohlen, dass dies als Repository -Geheimnis konfiguriert und als solche angegeben ist: `${{ secrets.CODECHECKER_PASSWORD }}` beim Konfigurieren der Aktion.
`store-run-name`	(automatisch generiert, im Format `user/repo: branchname` )	Codechecker -Analyse -Ausführungen werden in Läufe gesammelt. Ein Lauf korreliert normalerweise mit einer Konfiguration der Analyse. Läufe können schrittweise gespeichert werden. In diesem Fall kann Codechecker in der Lage sein, dass die Berichte festgelegt wurden.

`outputs` , die in weiteren Schritten verwendet werden sollen

Die Aktion enthält die folgenden Ausgänge, die in den Schritten eines Workflows der Analyse verwendet werden können.

Variable	Wert	Beschreibung
`analyze-output`	Automatisch erzeugte Eingabe oder `analyze-output` Eingabe	Das Verzeichnis, in dem die RAW -Analyse -Dateien (entweder von den Analysatoren erstellt oder vom Konverter erstellt wurden) verfügbar sind.
`codechecker-version`	Automatisch generiert (wahrscheinlich gleich wie bei der `version` )	Die Version des installierten Codecheckers, die die Analyse durchführte.
`codechecker-hash`	Automatisch generiert.	Der Git -Hash des installierten CodeCheckers, der die Analyse durchführte.
`logfile`	Automatisch generierte oder `logfile` Eingabe	Die JSON -Kompilierungsdatenbank der Ausführung der Analyse.
`llvm-version`	Automatisch generiert.	Die Vollversionszeichenfolge des installierten LLVM/Clang -Pakets (wie von `clang --version` gemeldet).
`diff-html-dir`	Automatisch generiert.	Das Verzeichnis, in dem die benutzerfreundlichen HTML- Fehlerberichte über die neuen Ergebnisse generiert wurden (falls `diff` aktiviert war).
`diff-result-log`	Automatisch generiert.	`CodeChecker cmd diff` Ausgangsprotokolldatei, die die neuen Befunde enthält, die hineingeladen sind.
`diff-run-name`	Automatisch erzeugte oder `diff-run-name` Eingabe	Der Name des Analyselaufs (falls `diff` aktiviert war), mit dem die Berichte verglichen wurden.
`result-html-dir`	Automatisch generiert.	Das Verzeichnis, in dem die benutzerfreundlichen HTML- Fehlerberichte generiert wurden.
`result-log`	Automatisch generiert.	Die Ausgabeprotokolldatei von `CodeChecker parse` , die die in sie abgelassenen Ergebnisse enthält.
`store-run-name`	Automatisch generierte oder `store-run-name` Eingabe	Der Name des Analyselaufs (falls `store` aktiviert war), auf den die Ergebnisse hochgeladen wurden.
`store-successful`	`true` oder `false`	Ob die Speicherung der Ergebnisse erfolgreich war. Nützlich, um den Build später zu brechen, um Networking -Ausfälle zu erkennen.
`warnings`	`true` oder `false`	Ob die statischen Analysatoren irgendwelche Ergebnisse berichteten.
`warnings-in-diff`	`true` oder `false`	Wenn `diff` aktiviert war, gab es im Vergleich zum Inhalt des Servers neue Ergebnisse in der aktuellen Analyse.

Expandieren

Zusätzliche Informationen

Version v1.0.4
Typ Andere Kategorien
Aktualisierungszeit 2025-06-23
Größe 27.16KB
Kommt von Github

Ähnliche Anwendungen

action download artifact

2024-11-05
Chinesische Version von Shadow Action

2024-08-03
Kriegsfeuer-Actionspiel

2024-03-04
Kapi Action App Android-Version

2024-01-05
Aktionskommando

2022-08-04
Aktion SuperCross

2022-07-23

CodeChecker Action

Codechecker C ++ statische Analyseaktion

Übersicht (für C-Familienprojekte)

Analyse des analysierenden Projekts

Projekte, die eine JSON -Kompilierungsdatenbank generieren und sauber erstellen können (kein generierter Code)

Projekte, die eine JSON-Kompilierungsdatenbank selbst erstellen müssen oder generierten Code erfordern

Brechen des Builds, wenn es statische Analysewarnungen gibt

Das Hochladen von Ergebnissen auf einen Codechecker -Server

Als CI -Tor bei Pull -Anfragen fungieren

Übersicht (für andere Analysen über den Berichtskonverter )

Ergebnisse hochladen und als CI -Tor fungieren

Aktionskonfiguration

Versionen zu installieren

Protokollkonfiguration erstellen

Analysekonfiguration

Berichtskonfiguration

Konfiguration der Konvertierung melden

Diff -Konfiguration

Konfiguration speichern

`outputs` , die in weiteren Schritten verwendet werden sollen

action download artifact

Chinesische Version von Shadow Action

Kriegsfeuer-Actionspiel

Kapi Action App Android-Version

Aktionskommando

Aktion SuperCross

chat.petals.dev

GPT Prompt Templates

GPTyped

IDArling

hextor

intellij tai e

Google Dorks

shepherd

mongo express

CodeChecker Action

Codechecker C ++ statische Analyseaktion

Übersicht (für C-Familienprojekte)

Analyse des analysierenden Projekts

Projekte, die eine JSON -Kompilierungsdatenbank generieren und sauber erstellen können (kein generierter Code)

Projekte, die eine JSON-Kompilierungsdatenbank selbst erstellen müssen oder generierten Code erfordern

Brechen des Builds, wenn es statische Analysewarnungen gibt

Das Hochladen von Ergebnissen auf einen Codechecker -Server

Als CI -Tor bei Pull -Anfragen fungieren

Übersicht (für andere Analysen über den Berichtskonverter )

Ergebnisse hochladen und als CI -Tor fungieren

Aktionskonfiguration

Versionen zu installieren

Protokollkonfiguration erstellen

Analysekonfiguration

Berichtskonfiguration

Konfiguration der Konvertierung melden

Diff -Konfiguration

Konfiguration speichern

outputs , die in weiteren Schritten verwendet werden sollen

`outputs` , die in weiteren Schritten verwendet werden sollen