dataset upgrade

Übersicht

codeql dataset upgrade [--threads=<num>] [--ram=<MB>] <options>... -- <dataset>

codeql dataset upgrade [--threads=<num>] [--ram=<MB>] <options>... -- <dataset>

Beschreibung

[Plumbing] Führt ein Upgrade für ein Dataset durch, damit es von den aktuellen Tools verwendet werden kann.

Dies entspricht codeql database upgrade, funktioniert aber nicht für die gesamte Datenbank, sondern für ein unformatiertes Dataset.

Optionen

Primäre Optionen

<dataset>

[Obligatorisch] Pfad zum unformatierten QL-Dataset, für das ein Upgrade ausgeführt werden soll.

--search-path=<dir>[:<dir>...]

Eine Liste mit Verzeichnissen, unter denen QL-Pakete mit Upgraderezepten zu finden sind. 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 Verzeichnisstrukturen enthält, definiert deren Reihenfolge die Rangfolge zwischen ihnen: Ist ein Paketname, der aufgelöst werden muss, in mehreren der Verzeichnisstrukturen vorhanden, 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.

(Hinweis: Unter Windows wird ; als Pfadtrennzeichen verwendet.)

--additional-packs=<dir>[:<dir>...]

[Erweitert] Bei Angabe dieser Verzeichnisliste werden die Verzeichnisse vor den Verzeichnissen in --search-path nach Upgrades 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 zu überschreiben. Einige interne Aktionen fügen diese Option direkt hinzu, wodurch alle konfigurierten Werte überschrieben werden.

(Hinweis: Unter Windows wird ; als Pfadtrennzeichen verwendet.)

--target-dbscheme=<file>

Das _Ziel_datenbankschema für das Upgrade. Ohne diese Angabe wird ein maximaler Upgradepfad erstellt.

--target-sha=<sha>

[Erweitert] Eine Alternative zu --target-dbscheme, die den internen Hash des Zieldatenbankschemas anstatt der Datenbankschemadatei angibt.

--[no-]allow-downgrades

Schließe alle relevanten Downgrades ein, wenn keine Upgrades vorhanden sind.

Optionen zum Steuern der Auswertung von Upgradeabfragen

--[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 RAM-Nutzung des Upgradeprozesses

-M, --ram=<MB>

Die Abfrageauswertung bemüht sich, ihren Gesamtspeicherbedarf unter diesem Wert zu halten. (Bei großen Datenbanken kann es jedoch vorkommen, dass der Schwellenwert durch dateigesicherte Speicherzuordnungen überschritten wird, die bei Speicherauslastung auf einen Datenträger ausgelagert werden können).

Der Wert sollte mindestens 2048 MB betragen; kleinere Werte werden transparent aufgerundet.

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.