Konfigurieren des CodeQL-Workflows für kompilierte Sprachen

Informationen zum CodeQL-Analyseworkflow und kompilierten Sprachen

Um GitHub für das code scanning deines Repositorys zu konfigurieren, musst du dem Repository einen GitHub Actions-Workflow hinzufügen. Für CodeQL code scanning füge CodeQL-Analyseworkflow hinzu. Weitere Informationen findest du unter Konfigurieren der Codeüberprüfung für ein Repository.

Normalerweise musst du die generierte Workflowdatei für code scanning nicht bearbeiten. Falls erforderlich, kannst du den Workflow jedoch bearbeiten, um einige der Einstellungen anzupassen. Du kannst z. B. den CodeQL-Analyseworkflow von GitHub bearbeiten, um die Häufigkeit der Scans, die zu scannenden Sprachen oder Verzeichnisse und was CodeQL code scanning in deinem Code sucht anzugeben. Möglicherweise musst du auch den CodeQL-Analyseworkflow bearbeiten, wenn du bestimmte Befehle verwendest, um deinen Code zu kompilieren. Allgemeine Informationen zum Konfigurieren der code scanning und zum Bearbeiten von Workflowdateien findest du unter Anpassen der Codeüberprüfung und Informationen zu GitHub Actions.

Informationen zu „autobuild“ für CodeQL

Von Code scanning werden Abfragen für eine oder mehrere Datenbanken ausgeführt. Jede Datenbank enthält eine Darstellung des gesamten Codes, der in einer einzelnen Sprache in deinem Repository vorliegt. In den kompilierten Sprachen C/C++, C#, und Java müssen beim Auffüllen dieser Datenbank zunächst der Code kompiliert und Daten extrahiert werden. Für diese Sprachen analysiert CodeQL die Quelldateien in deinem Repository, die erstellt werden. Für jede dieser Sprachen kannst du autobuild deaktivieren und stattdessen benutzerdefinierte Buildbefehle verwenden, um nur die Dateien zu analysieren, die von diesen benutzerdefinierten Befehlen erstellt werden.

Für die unterstützten kompilierten Sprachen kannst du den Code mithilfe der autobuild-Aktion im CodeQL-Analyseworkflow erstellen. So wird vermieden, dass du explizite Buildbefehle für C/C++, C#, und Java angeben musst.

Wenn dein Workflow eine language-Matrix verwendet, versucht autobuild, jede der kompilierten Sprachen zu kompilieren, die in der Matrix aufgeführt ist. Ohne eine Matrix, versucht autobuild, die unterstützte kompilierte Sprache mit den meisten Quelldateien im Repository zu kompilieren. Mit Ausnahme von Go schlägt die Analyse anderer kompilierter Sprachen in deinem Repository fehl, sofern du keine expliziten Buildbefehle angibst.

C/C++

Unterstütztes System	Systemname
Betriebssystem	Windows, macOS und Linux
Buildsystem	Windows: MSbuild und Buildskripts Linux und macOS: Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild und Buildskripts

Das Verhalten des autobuild-Schritts variiert je nach Betriebssystem, auf dem die Extraktion ausgeführt wird. Unter Windows versucht der autobuild-Schritt, mit dem folgenden Ansatz automatisch eine geeignete Buildmethode für C/C++ zu erkennen:

1. Für die Projektmappe (.sln) oder Projektdatei (.vcxproj), die sich am nächsten beim Stamm befindet, wird MSBuild.exe aufgerufen. Wenn autobuild mehrere Projektmappen oder Projektdateien mit dem gleichen (kürzesten) Abstand zum obersten Verzeichnis erkennt, versucht autobuild, alle zu kompilieren.
2. Ein Skript wird aufgerufen, das wie ein Buildskript aussieht: build.bat, build.cmd und build.exe (in dieser Reihenfolge).

Unter Linux und macOS werden die im Repository vorhandenen Dateien vom autobuild-Schritt überprüft, um das verwendete Buildsystem zu bestimmen:

1. Im Stammverzeichnis wird nach einem Buildsystem gesucht.
2. Wenn keines gefunden wird, werden die Unterverzeichnisse nach einem eindeutigen Verzeichnis mit einem Buildsystem für C/C++ durchsucht.
3. Ein passender Befehl wird ausgeführt, um das System zu konfigurieren.

C#

Unterstütztes System	Systemname
Betriebssystem	Windows und Linux
Buildsystem	.NET und MSbuild sowie Buildskripts

Der autobuild-Prozess versucht, mit dem folgenden Ansatz automatisch eine geeignete Buildmethode für C# zu erkennen:

1. Für die Projektmappe (.sln) oder Projektdatei (.csproj), die sich am nächsten beim Stamm befindet, wird dotnet build aufgerufen.
2. Für die Projektmappe oder Projektdatei, die sich am nächsten beim Stamm befindet, wird MSbuild (Linux) oder MSBuild.exe (Windows) aufgerufen. Wenn autobuild mehrere Projektmappen oder Projektdateien mit dem gleichen (kürzesten) Abstand zum obersten Verzeichnis erkennt, versucht autobuild, alle zu kompilieren.
3. Ein Skript wird aufgerufen, das wie ein Buildskript aussieht: build und build.sh (für Linux in dieser Reihenfolge) oder build.bat, build.cmd und build.exe (für Windows in dieser Reihenfolge).

Java

Unterstütztes System	Systemname
Betriebssystem	Windows, macOS und Linux (keine Einschränkung)
Buildsystem	Gradle, Maven und Ant

Der autobuild-Prozess versucht, mithilfe dieser Strategie das Buildsystem für Java-Codebasen zu bestimmen:

1. Im Stammverzeichnis wird nach einer Builddatei gesucht. Eine Prüfung auf Gradle-, dann Maven-, dann Ant-Builddateien erfolgt.
2. Die erste gefundene Builddatei wird ausgeführt. Wenn sowohl Gradle- als auch Maven-Dateien vorhanden sind, wird die Gradle-Datei verwendet.
3. Andernfalls wird in direkten Unterverzeichnissen des Stammverzeichnisses nach Builddateien gesucht. Wenn nur ein Unterverzeichnis Builddateien enthält, wird die erste Datei ausgeführt, die in diesem Unterverzeichnis ermittelt wurde (mit derselben Einstellung wie für 1). Wenn mehrere Unterverzeichnisse Builddateien enthalten, wird ein Fehler gemeldet.

Hinzufügen von Buildschritten für eine kompilierte Sprache

Wenn bei autobuild ein Fehler auftritt oder du andere Quelldateien als die durch den Prozess autobuild erstellten Dateien analysieren möchtest, musst du den Schritt autobuild aus dem Workflow entfernen und manuell Buildschritte hinzufügen. Für C/C++-, C#-, Go, und Java-Projekte analysiert CodeQL den Quellcode, der von den von dir angegebenen Buildschritten erstellt wird. Informationen zum Bearbeiten der Workflowdatei findest du unter Anpassen der Codeüberprüfung.

Nachdem du den autobuild-Schritt entfernt hast, hebe die Auskommentierung für den run-Schritt auf, und füge für dein Repository geeignete Buildbefehle hinzu. Der run-Schritt des Workflows führt Befehlszeilenprogramme mithilfe der Shell des Betriebssystems aus. Du kannst diese Befehle ändern und weitere Befehle hinzufügen, um den Buildprozess anzupassen.

- run: |
    make bootstrap
    make release

Weitere Informationen zum Schlüsselwort run findest du unter Workflowsyntax für GitHub Actions.

Wenn dein Repository mehrere kompilierte Sprachen enthält, kannst du sprachspezifische Buildbefehle angeben. Wenn dein Repository z. B. C/C++-, C#- und Java-Code enthält und autobuild C/C++ und C# ordnungsgemäß kompilieren kann, jedoch nicht Java, kannst du nach dem init-Schritt die folgende Konfiguration in deinem Workflow verwenden. Hiermit werden Buildschritte für Java angegeben, während weiterhin autobuild für C/C++ und C# verwendet wird:

- if: matrix.language == 'cpp' || matrix.language == 'csharp'
  name: Autobuild
  uses: github/codeql-action/autobuild@v1

- if: matrix.language == 'java'
  name: Build Java
  run: |
    make bootstrap
    make release

Weitere Informationen zur if-Bedingung findest du unter Workflowsyntax für GitHub Actions.

Weitere Tipps und Tricks dazu, warum dein Code nicht von autobuild erstellt wird, findest du unter Problembehandlung für den CodeQL-Workflow.

Wenn du manuelle Buildschritte für kompilierte Sprachen hinzugefügt hast und code scanning in deinem Repository noch immer nicht funktioniert, kontaktiere deine Websiteadministrator*innen.