À propos des codes de sortie
L’CodeQL CLI indique l’état de chaque commande qu’elle exécute sous la forme d’un code de sortie. Ce code de sortie fournit des informations pour les commandes suivantes ou pour d’autres outils qui s’appuient sur l’CodeQL CLI.
0
Réussite, arrêt normal.
1
La commande a réussi à déterminer que la réponse à votre question est « non ».
Ce code de sortie n’est utilisé que par quelques commandes, telles que test run, dataset check, query format et resolve extractor. Pour plus d’informations, consultez la documentation de ces commandes.
2
Nous avons rencontré un défi.
L’interface CLI écrit un message d’erreur explicite dans stderr.
Sont inclus les cas où un extracteur échoue avec une erreur interne, car le pilote codeql ne parvient pas à faire la distinction entre les erreurs internes et les erreurs présentées à l’utilisateur dans le comportement de l’extracteur.
3
Le lanceur n’a pas réussi à trouver le répertoire d’installation de CodeQL.
Dans ce cas, le lanceur ne peut pas du tout démarrer le code Java pour l’CodeQL CLI. Cette erreur ne doit se produire qu’en cas de sérieux problème avec l’installation de CodeQL.
32
L’extracteur n’a trouvé aucun code à analyser lors de l’exécution de database create ou database finalize.
33
Une ou plusieurs évaluations de requête ont expiré.
Il est possible que certaines requêtes évaluées en parallèle n’aient pas expiré. Les résultats de ces requêtes sont générés comme d’habitude.
98
L’évaluation a été explicitement annulée.
99
L’CodeQL CLI a manqué de mémoire.
Cela ne signifie pas nécessairement que toute la RAM physique de la machine a été utilisée.
Si vous n’utilisez pas l’option --ram pour définir une limite explicitement, la JVM décide d’une limite par défaut au démarrage.
100
Une erreur interne fatale s’est produite.
Celle-ci doit être considérée comme un bogue. L’interface CLI écrit généralement une description d’erreur abrégée dans stderr.
Si vous pouvez reproduire le bogue, il convient d’utiliser --logdir et d’envoyer les fichiers journaux à GitHub dans un rapport de bogue.
Autre
En cas de problèmes vraiment graves au sein de la JVM qui exécute codeql, un code de sortie différent de zéro choisi par la machine elle-même peut être retourné.
Cette situation ne doit se produire qu’en cas de problème sérieux avec l’installation de CodeQL ou en cas de problème de mémoire avec le système hôte exécutant le processus CodeQL. Par exemple, les systèmes Unix peuvent retourner le code de sortie 137 pour indiquer que le noyau a tué un processus que CodeQL a démarré. Une façon de résoudre ce problème consiste à modifier votre indicateur –ram= pour l’étape codeql database analyze, puis à réexécuter votre workflow.