In diesem Inhalt wird die neueste Version von CodeQL CLI beschrieben. Weitere Informationen zu diesem Thema findest du unter https://github.com/github/codeql-cli-binaries/releases.
Um Details zu den Optionen anzuzeigen, die für diesen Befehl in früheren Releases verfügbar sind, führe den Befehl mit der Option --help
im Terminal aus.
Übersicht
codeql execute queries [--output=<dir|file.bqrs>] [--threads=<num>] <options>... -- <dataset> <query|dir|suite|pack>...
codeql execute queries [--output=<dir|file.bqrs>] [--threads=<num>] <options>... -- <dataset> <query|dir|suite|pack>...
Beschreibung
[Plumbing] Führt mindestens eine Abfrage für ein Dataset aus.
Dieser Befehl sollte normalerweise nicht direkt aufgerufen werden. Verwende stattdessen entweder codeql database run-queries oder codeql query run, die codeql execute queries mit bestimmten JVM-Optionen starten und damit die Leistung des QL-Evaluators optimieren.
Optionen
Primäre Optionen
<dataset>
[Obligatorisch] Pfad zum unformatierten QL-Dataset, das abgefragt werden soll.
<querysuite|pack>...
[Obligatorisch] Auszuführende Abfragen. Jedes Argument hat die Form scope/name@range:path
. Dabei gilt Folgendes:
scope/name
ist der qualifizierte Name eines CodeQL-Pakets.range
ist ein SemVer-Bereich.path
ist ein Dateisystempfad.
Wenn ein scope/name
angegeben ist, sind range
und path
optional. Ein fehlender range
impliziert die neueste Version des angegebenen Pakets. Ein fehlender path
impliziert die Standardabfragesammlung des angegebenen Pakets.
Der path
kann Folgendes sein: eine *.ql
-Abfragedatei, ein Verzeichnis mit einer oder mehreren Abfragen oder eine .qls
-Abfragesammlungsdatei. Wenn kein Packname angegeben ist, muss ein path
angegeben werden, der relativ zum Arbeitsverzeichnis des aktuellen Prozesses interpretiert wird.
Um einen path
anzugeben, der die Literale @
oder :
enthält, verwendest du path:
als Präfix für das Argument: path:directory/with:and@/chars
.
Wenn du einen scope/name
und einen path
angibst, kann der path
nicht absolut sein. Er wird als relativ zum Stamm des CodeQL-Pakets ausgewertet.
-o, --output=<dir|file.bqrs>
In der Regel ist dies ein vorhandenes Verzeichnis, in das die BQRS-Ausgabe der Abfragen geschrieben wird. Dateinamen in diesem Verzeichnis werden von den QL-Dateinamen abgeleitet.
Wenn genau eine Abfrage ausgeführt werden soll, kann dies auch der Name der tatsächlich zu schreibenden BQRS-Datei sein. Es kann auch keine Angabe erfolgen, um eine für Menschen lesbare Darstellung der Ergebnisse an die Standardausgabe zu schreiben.
--no-rerun
Lässt die Auswertung von Abfragen aus, für die bereits ein BQRS-Ergebnis am Ausgabespeicherort gespeichert ist.
Optionen zum Steuern der zu verwendenden Bedrohungsmodelle
--threat-model=<name>...
Eine Liste der Bedrohungsmodelle, die aktiviert oder deaktiviert werden sollen.
Das Argument ist der Name eines Bedrohungsmodells, dem optional ein „!“ vorangestellt ist. Wenn kein ‚!’ vorhanden ist, werden das benannte Bedrohungsmodell und alle untergeordneten Elemente aktiviert. Wenn ein ‚!’ vorhanden ist, werden das benannte Bedrohungsmodell und alle untergeordneten Elemente deaktiviert.
Das Bedrohungsmodell ‚Standard’ ist standardmäßig aktiviert, kann jedoch durch Angabe von ‚---threat-model !default’ deaktiviert werden.
Das Bedrohungsmodell ‚alle’ kann verwendet werden, um alle Bedrohungsmodelle zu aktivieren oder zu deaktivieren.
Die Optionen für das --Bedrohungsmodell werden in der entsprechenden Reihenfolge verarbeitet. Beispielsweise ermöglicht ‚---threat-model local --threat-model !environment’ alle Bedrohungsmodelle in der Gruppe ‚lokal’, mit Ausnahme des Bedrohungsmodells ‚Umgebung’.
Diese Option hat nur Auswirkungen auf Sprachen, die Bedrohungsmodelle unterstützen.
Verfügbar seit v2.15.3
.
Optionen zum Steuern der Abfrageauswertung
--[no-]tuple-counting
[Erweitert] Zeigt die Tupelanzahl für jeden Auswertungsschritt in den Protokollen der Abfrageauswertung an. Bei Angabe der Option --evaluator-log
wird die Tupelanzahl sowohl in die textbasierten als auch in die strukturierten JSON-Protokolle eingeschlossen, die durch den Befehl erstellt werden. (Dies kann bei der Optimierung der Leistung von komplexem QL-Code hilfreich sein.)
--timeout=<seconds>
[Erweitert] Dient zum Festlegen der Timeoutlänge für die Abfrageauswertung in Sekunden.
Das Timeoutfeature ist für Fälle vorgesehen, in denen die Auswertung einer komplexen Abfrage zu lange dauern würde. Es ist keine effektive Methode zur Begrenzung der Gesamtdauer der Abfrageauswertung. Die Auswertung kann fortgesetzt werden, solange jeder Teil der Berechnung, für den eine separate Zeiterfassung erfolgt, innerhalb des Timeouts abgeschlossen wird. Derzeit sind diese Teile mit separater Zeiterfassung „RA-Ebenen“ der optimierten Abfrage. Dies kann sich aber noch ändern.
Ohne Timeoutangabe oder bei Angabe eines Nullwerts wird kein Timeout festgelegt. (Einzige Ausnahme ist codeql test run: Hier gilt ein Standardtimeout von fünf Minuten.)
-j, --threads=<num>
Dient zum Festlegen, wie viele Threads für die Abfrageauswertung verwendet werden sollen.
Der Standardwert lautet 1. Du kannst 0 übergeben, um jeweils einen Thread pro Kern auf dem Computer zu verwenden, oder -N, um N Kerne ungenutzt zu lassen. (Es wird allerdings immer noch mindestens ein Thread verwendet.)
--[no-]save-cache
[Erweitert] Dient zum aggressiven Schreiben von Zwischenergebnissen in den Datenträgercache. Dies nimmt mehr Zeit in Anspruch und benötigt (viel) mehr Speicherplatz, kann jedoch die nachfolgende Ausführung ähnlicher Abfragen beschleunigen.
--[no-]expect-discarded-cache
[Erweitert] Hiermit kannst du entscheiden, welche Prädikate ausgewertet werden sollen und was in den Datenträgercache geschrieben werden soll (basierend auf der Annahme, dass der Cache nach Ausführung der Abfragen geleert wird).
--[no-]keep-full-cache
[Erweitert] Dient zum Festlegen, dass der Datenträgercache nach Abschluss der Auswertung nicht bereinigt werden soll. Das kann Zeit sparen, wenn du später ohnehin codeql dataset cleanup oder codeql database cleanup verwendest.
--max-disk-cache=<MB>
Dient zum Festlegen des maximalen Speicherplatzes, der vom Datenträgercache für Zwischenergebnisse von Abfragen beansprucht werden darf.
Wird diese Größe nicht explizit konfiguriert, versucht der Auswerter, basierend auf der Größe des Datasets und der Komplexität der Abfragen eine angemessene Menge an Cachespeicherplatz zu verwenden. Durch explizites Festlegen eines höheren Grenzwerts (im Vergleich zur Standardnutzung) können mehr Daten zwischengespeichert werden, was spätere Abfragen beschleunigen kann.
--min-disk-free=<MB>
[Erweitert] Dient zum Festlegen der Zielmenge des freien Speicherplatzes im Dateisystem.
Ohne Angabe von --max-disk-cache
versucht der Auswerter nach Möglichkeit, die Nutzung des Datenträgercaches einzuschränken, wenn der freie Speicherplatz im Dateisystem diesen Wert unterschreitet.
--min-disk-free-pct=<pct>
[Erweitert] Dient zum Festlegen des Zielanteils des freien Speicherplatzes im Dateisystem.
Ohne Angabe von --max-disk-cache
versucht der Auswerter nach Möglichkeit, die Nutzung des Datenträgercaches einzuschränken, wenn der freie Speicherplatz im Dateisystem diesen Prozentsatz unterschreitet.
--external=<pred>=<file.csv>
Eine CSV-Datei, die Zeilen für das externe Prädikat <pred> enthält.
Für --external
können mehrere Optionen angegeben werden.
--xterm-progress=<mode>
[Erweitert] Steuert, ob die Statusnachverfolgung während der QL-Auswertung mithilfe von xterm-Steuersequenzen angezeigt werden soll. Mögliche Werte:
no
: Generiert keinen aufwendigen Status und geht von einem einfachen Terminal aus.
auto
(Standardwert): Ermittelt automatisch, ob der Befehl in einem geeigneten Terminal ausgeführt wird.
yes
: Geht davon aus, dass das Terminal mit xterm-Kontrollsequenzen kompatibel ist. Das Feature muss weiterhin die Größe des Terminals automatisch ermitteln können, und wird bei Angabe von -q
deaktiviert.
25x80
(oder ähnlich): Wie yes
, und gibt auch explizit die Größe des Terminals an.
25x80:/dev/pts/17
(oder ähnlich): Zeigt einen aufwendigen Status in einem anderen Terminal als stderr an. In erste Linie für interne Tests nützlich.
Optionen zum Steuern der Ausgabe strukturierter Auswertungsprotokolle
--evaluator-log=<file>
[Erweitert] Dient zum Ausgeben strukturierter Protokolle zur Leistung des Auswerters für die angegebene Datei. Das Format dieser Protokolldatei kann ohne vorherige Ankündigung geändert werden. Es handelt sich jedoch um einen Datenstrom von JSON-Objekten, die entweder durch zwei Neue-Zeile-Zeichen (standardmäßig) getrennt werden – oder durch ein einzelnes, wenn die Option --evaluator-log-minify
übergeben wird. Verwende codeql generate log-summary <file>
, um eine stabilere Zusammenfassung dieser Datei zu erstellen, und vermeide eine direkte Analyse der Datei. Die Datei wird überschrieben, wenn sie bereits vorhanden ist.
--evaluator-log-minify
[Erweitert] Wenn die Option --evaluator-log
zusammen mit dieser Option übergeben wird, wird die Größe des generierten JSON-Protokolls minimiert. Dies beeinträchtigt allerdings die Lesbarkeit.
Optionen zum Steuern der QL-Kompilierung
--warnings=<mode>
Behandeln von Warnungen vom QL-Compiler Enthält einen der folgenden Werte:
hide
: unterdrückt Warnungen
show
(Standard) : gibt Warnungen aus, setzt die Kompilierung aber fort.
error
: behandelt Warnungen als Fehler.
--no-debug-info
Gibt keine Informationen zum Quellspeicherort in RA zum Debuggen aus.
--[no-]fast-compilation
[Veraltet] [Erweitert] Lässt besonders langsame Optimierungsschritte aus.
--no-release-compatibility
[Erweitert] Verwendet die neuesten Compilerfeatures auf Kosten der Portabilität.
Von Zeit zu Zeit werden neue QL-Sprachfeatures und Evaluatoroptimierungen vom QL-Evaluator für einige Releases unterstützt, bevor sie standardmäßig im QL-Compiler aktiviert werden. Dadurch wird sichergestellt, dass die Leistung beim Entwickeln von Abfragen mit dem neuesten CodeQL-Release auch von etwas älteren Releases erreicht werden kann, die möglicherweise noch für die Codeüberprüfung oder CI-Integrationen verwendet werden.
Wenn es für dich nicht wichtig ist, ob deine Abfragen mit anderen (früheren oder späteren) CodeQL-Releases kompatibel sind, kannst du manchmal eine etwas höhere Leistung erzielen, indem du dieses Flag verwendest, um die neuesten Verbesserungen im Compiler frühzeitig zu aktivieren.
Wenn Releases keine neuen Verbesserungen aufweisen, führt diese Option im Hintergrund keine Aktionen aus. Daher kannst du sie bedenkenlos dauerhaft in deiner globalen CodeQL-Konfigurationsdatei festlegen.
Verfügbar seit v2.11.1
.
--[no-]local-checking
Führt die anfänglichen Überprüfungen nur für den verwendeten Teil der QL-Quelle durch.
--no-metadata-verification
Überprüft eingebettete Abfragemetadaten in QLDoc-Kommentaren nicht auf Gültigkeit.
--compilation-cache-size=<MB>
[Erweitert] Setzt den Standardwert für die maximale Größe des Verzeichnisse für den Kompilierungscache außer Kraft.
--fail-on-ambiguous-relation-name
[Erweitert] Schlägt die Kompilierung fehl, wenn während der Kompilierung ein mehrdeutiger Beziehungsname generiert wird.
Optionen zum Einrichten der Kompilierungsumgebung
--search-path=<dir>[:<dir>...]
Eine Liste der Verzeichnisse, in denen QL-Pakete gefunden werden können. Jedes Verzeichnis kann entweder ein QL-Paket (oder ein Bündel von Paketen mit einer Datei vom Typ .codeqlmanifest.json
am Stamm) oder das unmittelbar übergeordnete Element eines oder mehrerer solcher Verzeichnisse sein.
Wenn der Pfad mehrere Verzeichnisse enthält, definiert deren Reihenfolge ihre Rangfolge: Ist ein Paketname, der aufgelöst werden muss, in mehreren der Verzeichnisstrukturen enthalten, wird die erste Angabe verwendet.
Ein entsprechender Verweis beim Auschecken des Open-Source-CodeQL-Repositorys sollte funktionieren, wenn eine der darin enthaltenen Sprachen abgefragt wird.
Wenn du das CodeQL-Repository als gleichgeordnetes Element der entpackten CodeQL-Toolkette ausgecheckt hast, musst du diese Option nicht verwenden. Solche gleichgeordneten Verzeichnisse werden immer nach QL-Paketen durchsucht, die andernfalls nicht gefunden werden können. (Wenn diese Standardeinstellung nicht funktioniert, solltest du unbedingt --search-path
in einer Benutzerkonfigurationsdatei festlegen.)
(Hinweis: Unter Windows wird ;
als Pfadtrennzeichen verwendet.)
--additional-packs=<dir>[:<dir>...]
Bei Angabe dieser Verzeichnisliste werden die Verzeichnisse vor den Verzeichnissen in --search-path
nach Paketen durchsucht. Die Reihenfolge zwischen diesen Elementen spielt keine Rolle. Wenn ein Paketname über diese Liste an zwei verschiedenen Stellen gefunden wird, handelt es sich um einen Fehler.
Dies ist hilfreich, wenn du vorübergehend eine neue Version eines Pakets entwickelst, die auch am Standardpfad vorhanden ist. Andererseits wird davon abgeraten, diese Option in einer Konfigurationsdatei außer Kraft zu setzen. Einige interne Aktionen fügen diese Option direkt hinzu, wodurch alle konfigurierten Werte überschrieben werden.
(Hinweis: Unter Windows wird ;
als Pfadtrennzeichen verwendet.)
--library-path=<dir>[:<dir>...]
[Erweitert] Eine optionale Liste von Verzeichnissen, die dem unformatierten Suchpfad für den Import von QL-Bibliotheken hinzugefügt werden. Sollte nur verwendet werden, wenn du QL-Bibliotheken verwendest, die nicht als QL-Pakete gepackt wurden.
(Hinweis: Unter Windows wird ;
als Pfadtrennzeichen verwendet.)
--dbscheme=<file>
[Erweitert] Definiert explizit, für welche Abfragen des Datenbankschemas kompiliert werden sollen. Sollte nur von Aufrufer*innen angegeben werden, die sehr genau wissen, was sie tun.
--compilation-cache=<dir>
[Erweitert] Gibt ein zusätzliches Verzeichnis an, das als Kompilierungscache verwendet werden soll.
--no-default-compilation-cache
[Erweitert] Verwendet keine Kompilierungscaches an Standardspeicherorten, z. B. im QL-Paket mit der Abfrage oder im Verzeichnis der CodeQL-Toolkette.
Optionen zum Konfigurieren des CodeQL-Paket-Managers
--registries-auth-stdin
Führt eine Authentifizierung bei GitHub Enterprise Server-Containerregistrierungen durch, indem eine durch Trennzeichen getrennte Liste von <registry_url>=<token>-Paaren übergeben wird.
Du kannst https://containers.GHEHOSTNAME1/v2/=TOKEN1,https://containers.GHEHOSTNAME2/v2/=TOKEN2
übergeben,
um dich bei zwei GitHub Enterprise Server-Instanzen zu authentifizieren.
Dadurch werden die Umgebungsvariablen CODEQL_REGISTRIES_AUTH und GITHUB_TOKEN überschrieben. Wenn du dich nur bei der Containerregistrierung von github.com authentifizieren musst, kannst du dich stattdessen mit der einfacheren Option --github-auth-stdin
authentifizieren.
--github-auth-stdin
Authentifiziere dich bei der Containerregistrierung auf github.com, indem du auf github.com ein GitHub Apps-Token oder ein persönliches Zugriffstoken über die Standardeingabe übergibst.
Für die Authentifizierung bei Containerregistrierungen in GitHub Enterprise Server übergibst du --registries-auth-stdin
oder verwendest die Umgebungsvariable „CODEQL_REGISTRIES_AUTH“.
Dadurch wird die GITHUB_TOKEN-Umgebungsvariable überschrieben.
Allgemeine Optionen
-h, --help
Zeigt diesen Hilfetext an.
-J=<opt>
[Erweitert] Dient zum Angeben einer Option für die JVM-Instanz, die den Befehl ausführt.
(Beachte, dass Optionen, die Leerzeichen enthalten, nicht ordnungsgemäß verarbeitet werden.)
-v, --verbose
Ermöglicht die inkrementelle Erhöhung der Anzahl ausgegebener Statusmeldungen.
-q, --quiet
Ermöglicht die inkrementelle Verringerung der Anzahl ausgegebener Statusmeldungen.
--verbosity=<level>
[Erweitert] Dient zum expliziten Festlegen des Ausführlichkeitsgrads auf „errors“, „warnings“, „progress“, „progress+“, „progress++“ oder „progress+++“. Überschreibt -v
und -q
:
--logdir=<dir>
[Erweitert] Ermöglicht das Schreiben detaillierter Protokolle in eine oder mehrere Dateien im angegebenen Verzeichnis mit generierten Namen, die Zeitstempel und den Namen des ausgeführten Unterbefehls enthalten.
(Um eine Protokolldatei mit einem Namen zu schreiben, über den du die volle Kontrolle hast, gib stattdessen --log-to-stderr
an, und leite stderr wie gewünscht um.)
--common-caches=<dir>
[Erweitert] Steuert den Speicherort zwischengespeicherter Daten auf dem Datenträger, der zwischen mehreren Ausführungsvorgängen der CLI beibehalten wird, z. B. heruntergeladene QL-Pakete und kompilierte Abfragepläne. Wenn dies nicht explizit festgelegt ist, wird dieses Verzeichnis standardmäßig auf ein Verzeichnis mit dem Namen .codeql
festgelegt, das sich im Startverzeichnis des Benutzer. Es wird erstellt, wenn es noch nicht vorhanden ist.
Verfügbar seit v2.15.2
.