Publication et utilisation de packs CodeQL

Remarque : la fonctionnalité de gestion de packages CodeQL, y compris des packs CodeQL, est actuellement disponible en version bêta et peut faire l’objet de modifications. Pendant la version bêta, les packs CodeQL sont disponibles uniquement à l’aide de packages GitHub, à savoir le Container registry. Pour utiliser cette fonctionnalité bêta, installez la dernière version du bundle CodeQL CLI à partir de : https://github.com/github/codeql-action/releases.

Configuration du fichier `qlpack.yml` avant la publication

Remarque : cet article décrit les fonctionnalités disponibles avec l’offre groupée CodeQL CLI 2.12.7 incluse dans la mise en production initiale de GitHub Enterprise Server 3.7.

Si votre administrateur de site a mis à jour votre versionCodeQL CLI vers une version plus récente, consultez la version GitHub Enterprise Cloud de cet article pour obtenir plus d’informations sur les dernières fonctionnalités.

Vous pouvez vérifier et modifier les détails de configuration de votre pack CodeQL avant la publication. Ouvrez le fichier qlpack.yml dans l’éditeur de texte de votre choix.

library: # set to true if the pack is a library. Set to false or omit for a query pack
name: <scope>/<pack>
version: <x.x.x>
description: <Description to publish with the package>
default-suite: # optional, one or more queries in the pack to run by default
    - query: <relative-path>/query-file>.ql
default-suite-file: default-queries.qls # optional, a pointer to a query-suite in this pack
license: # optional, the license under which the pack is published
dependencies: # map from CodeQL pack name to version range

name: doit avoir le format <scope>/<pack>, où <scope> est l’organisation GitHub dans laquelle vous allez publier et est le nom du pack.
Un maximum d’une default-suite ou d’un default-suite-file est autorisé. Il existe deux façons différentes de définir une suite de requêtes par défaut à exécuter : la première en spécifiant des requêtes directement dans le fichier qlpack.yml et la seconde en spécifiant une suite de requêtes dans le pack.

En cours d’exécution `codeql pack publish`

Quand vous êtes prêt à publier un pack dans GitHub Container registry, vous pouvez exécuter la commande suivante à la racine du répertoire du pack :

codeql pack publish

Le package publié s’affiche dans la section des packages de l’organisation GitHub spécifiée par l’étendue dans le fichier qlpack.yml.

En cours d’exécution `codeql pack download <scope>/<pack>`

Pour exécuter un pack créé par quelqu’un d’autre, vous devez d’abord le télécharger en exécutant la commande suivante :

codeql pack download <scope>/<pack>@x.x.x

<scope> : nom de l’organisation GitHub à partir de laquelle vous allez télécharger.
<pack> : nom du pack que vous voulez télécharger.
@x.x.x : numéro de version facultatif. S’il est omis, c’est la dernière version qui est téléchargée.

Cette commande accepte des arguments pour plusieurs packs.

Utilisation d’un pack CodeQL pour analyser une base de données CodeQL

Pour analyser une base de données CodeQL avec un pack CodeQL, exécutez la commande suivante :

codeql database analyze <database> <scope>/<pack>@x.x.x:<path>

<database> : base de données CodeQL à analyser.
<scope> : nom de l’organisation GitHub sur laquelle le pack est publié.
<pack> : nom du pack que vous utilisez.
@x.x.x : numéro de version facultatif. S’il est omis, c’est la dernière version qui est utilisée.
:<path> : chemin facultatif d’une requête, d’un répertoire ou d’une suite de requêtes. S’il est omis, c’est la suite de requêtes par défaut du pack qui est utilisée.

La commande analyze exécute la suite par défaut des packs CodeQL spécifiés. Vous pouvez spécifier plusieurs packs CodeQL à utiliser pour analyser une base de données CodeQL. Par exemple :

codeql <database> analyze <scope>/<pack> <scope>/<other-pack>

Utilisation de packs CodeQL sur GitHub Enterprise Server

Par défaut, CodeQL CLI s’attend à télécharger des packs CodeQL depuis Container registry sur GitHub.com et à publier des packs sur celui-ci. Cependant, vous pouvez aussi utiliser des packs CodeQL dans un Container registry sur GitHub Enterprise Server en créant un fichier qlconfig.yml pour indiquer à l’interface CLI quel Container registry utiliser pour chaque pack.

Créez un fichier ~/.codeql/qlconfig.yml en utilisant votre éditeur de texte préféré, et ajoutez des entrées pour spécifier le registre à utiliser pour un ou plusieurs modèles de nom de package. Par exemple, le fichier qlconfig.yml suivant associe tous les packs au Container registry pour le GitHub Enterprise Server au niveau de GHE_HOSTNAME, à l’exception des packs correspondant à codeql/\*, qui sont associés au Container registry sur GitHub.com :

registries:
- packages:
  - 'codeql/*'
  - 'other-org/*'
  url: https://ghcr.io/v2/
- packages: '*'
  url: https://containers.GHE_HOSTNAME/v2/

CodeQL CLI va déterminer quel registre utiliser pour un nom de package donné en recherchant le premier élément de la liste registries avec une propriété packages qui correspond à ce nom de package. Cela signifie que vous allez généralement d’abord définir les modèles de nom de package les plus spécifiques. La propriété packages peut être un seul nom de package, un modèle Glob, ou une liste YAML de noms de package et de modèles Glob.

La liste registries peut aussi être placée à l’intérieur d’un fichier codeql-workspace.yml. Procéder ainsi vous permet de définir les registres à utiliser dans un espace de travail spécifique, afin qu’il puisse être partagé entre d’autres utilisateurs CodeQL de l’espace de travail. La liste registries dans le fichier codeql-workspace.yml sera fusionnée avec la liste du fichier qlconfig.yml global et sera prioritaire sur celle-ci. Pour plus d’informations sur codeql-workspace.yml, consultez « À propos des espaces de travail CodeQL ».

Vous pouvez maintenant utiliser codeql pack publish, codeql pack download et codeql database analyze pour gérer des packs sur GitHub Enterprise Server.

Authentification auprès des Container registries

GitHub

Vous pouvez publier des packs et télécharger des packs privés en vous authentifiant auprès du Container registry GitHub approprié.

Vous pouvez vous authentifier auprès du Container registry sur GitHub.com de deux façons :

Passer l’option --github-auth-stdin à CodeQL CLI, puis fournir un jeton GitHub Apps ou un personal access token via une entrée standard.
Définir la variable d’environnement GITHUB_TOKEN sur un jeton GitHub Apps ou un personal access token.

De même, vous pouvez vous authentifier auprès d’un Container registry GitHub Enterprise Server ou vous authentifier auprès de plusieurs registres simultanément (par exemple pour télécharger ou exécuter des packs privés de plusieurs registres) de deux façons :

Passer l’option --registries-auth-stdin à CodeQL CLI, puis fournir une chaîne d’authentification de registre via une entrée standard.
Définir la variable d’environnement CODEQL_REGISTRIES_AUTH sur une chaîne d’authentification de registre.

Une chaîne d’authentification de registre est une liste de paires <registry-url>=<token> séparées par des virgules, où registry-url est une URL de Container registry, comme https://containers.GHE_HOSTNAME/v2/, et où token est un jeton GitHub Apps ou un personal access token pour ce Container registry GitHub. Ceci garantit que chaque jeton est passé seulement au Container registry que vous spécifiez. Par exemple, la chaîne d’authentification de registre suivante spécifie que CodeQL CLI doit s’authentifier auprès du Container registry sur GitHub.com en utilisant le jeton <token1> et auprès du Container registry pour l’instance GHES de GHE_HOSTNAME en utilisant le jeton <token2> :

https://ghcr.io/v2/=<token1>,https://containers.GHE_HOSTNAME/v2/=<token2>

À propos des fichiers `qlpack.yml`

Durant l’exécution de commandes liées aux requêtes, CodeQL recherche d’abord les fichiers qlpack.yml dans les répertoires frères du répertoire d’installation (et leurs sous-répertoires). Ensuite, il recherche dans le cache de package les packs CodeQL qui ont été téléchargés. Cela signifie que quand vous développez des requêtes localement, les packages locaux dans le répertoire d’installation remplacent les packages du même nom dans le cache de package pour que vous puissiez tester vos modifications locales.

Les métadonnées de chaque fichier qlpack.yml indiquent à CodeQL comment compiler les requêtes dans le pack, les bibliothèques dont dépend le pack et où trouver les définitions des suites de requêtes.

Le contenu du pack CodeQL (requêtes ou bibliothèques utilisées dans l’analyse CodeQL) est inclus dans le même répertoire que qlpack.yml ou dans ses sous-répertoires.

Le répertoire contenant le fichier qlpack.yml sert de répertoire racine pour le contenu du pack CodeQL. Autrement dit, pour tous les fichiers .ql et .qll du pack, CodeQL résout toutes les instructions d’importation relatives au répertoire contenant le fichier qlpack.yml à la racine du pack.

Propriétés `qlpack.yml`

Les propriétés suivantes sont prises en charge dans les fichiers qlpack.yml.

`name`

Nécessaire pour tous les packs.
Définit l’étendue du pack, où le pack CodeQL est publié et le nom du pack défini avec des caractères alphanumériques et des traits d’union. Elle doit être unique, car CodeQL ne peut pas faire la différence entre des packs CodeQL ayant des noms identiques. Utilisez le nom du pack pour spécifier les requêtes à exécuter à l’aide de database analyze et pour définir des dépendances entre les packs CodeQL (consultez les exemples ci-dessous). Par exemple :
```
name: octo-org/security-queries
```

`version`

Nécessaire pour tous les packs publiés.
Définit une version sémantique pour ce pack CodeQL, qui doit respecter la spécification SemVer v2.0.0. Par exemple :
```
version: 0.0.0
```

`dependencies`

Nécessaire pour les packs de requêtes et de bibliothèques qui définissent des dépendances de package CodeQL sur d’autres packs. Les packs de modèles ne peuvent pas définir de dépendances et utilisent extensionTargets à la place.
Définit un mappage entre les références de pack et la plage de versions sémantiques compatible avec ce pack. Prise en charge pour les versions v2.6.0 et ultérieures de CodeQL CLI. Par exemple :
```
dependencies:
  codeql/cpp-all: ^0.0.2
```

`defaultSuiteFile`

Nécessaire pour les packs qui exportent un ensemble de requêtes par défaut à exécuter.
Définit le chemin d’accès à un fichier de suites de requêtes par rapport à la racine du package, contenant toutes les requêtes exécutées par défaut lorsque ce pack est passé à la commande codeql database analyze. Prise en charge à partir de la version v2.6.0 de l’interface CLI. Un seul defaultSuiteFile ou defaultSuite peut être défini. Par exemple :
```
defaultSuiteFile: cpp-code-scanning.qls
```

`defaultSuite`

Nécessaire pour les packs qui exportent un ensemble de requêtes par défaut à exécuter.
Définit une suite de requêtes inlined contenant toutes les requêtes exécutées par défaut quand ce pack est transféré à la commande codeql database analyze. Prise en charge à partir de la version v2.6.0 de l’interface CLI. Un seul defaultSuiteFile ou defaultSuite peut être défini. Par exemple :
```
defaultSuite:
  queries: .
  exclude:
    precision: medium
```

`groups`

facultatif.
Définit des regroupements logiques de packs dans un espace de travail CodeQL. L’utilisation de groupes est un moyen d’appliquer des opérations de pack à des sous-ensembles de packs dans un espace de travail. Par exemple, le pack suivant est défini comme faisant partie des groupes java et experimental :
```
groups:
  - java
  - experimental
```
L’exécution de codeql pack publish --groups java,-experimental publie tous les packs dans le groupe java, à l’exception des packs experimental. Vous pouvez exécuter la commande codeql pack ls --groups [-]<group>[,[-]<group>...] pour répertorier les packs dans un espace de travail qui correspondent à l’ensemble spécifié de groupes.

Un pack CodeQL dans l’espace de travail donné est inclus dans la liste si :
- Il se trouve dans au moins un des groupes cités sans signe moins (cette condition est automatiquement remplie en l’absence de groupe sans signe moins).
- Il ne se trouve dans aucun groupe listé avec un signe moins.

`library`

Nécessaire pour les packs de bibliothèques.
Définit une valeur booléenne qui indique si ce pack est un pack de bibliothèques. Les packs de bibliothèques ne contiennent pas de requête et ne sont pas compilés. Les packs de requêtes peuvent ignorer ce champ ou le définir explicitement sur false. Par exemple :
```
library: true
```

`suites`

Facultative pour les packs qui définissent des suites de requêtes.
Définit le chemin d’un répertoire dans le pack, contenant les suites de requêtes que vous souhaitez faire connaître de CodeQL CLI (chemin relatif par rapport au répertoire du pack). Les utilisateurs du pack CodeQL peuvent exécuter des suites connues stockées dans ce répertoire en spécifiant le nom du pack sans fournir leur chemin complet. Ceci n’est pas pris en charge pour les packs CodeQL téléchargés à partir du registre de conteneurs. Pour plus d’informations sur les suites de requêtes, consultez « Création de suites de requêtes CodeQL ». Par exemple :
```
suites: octo-org-query-suites
```

`tests`

Facultative pour les packs contenant des tests CodeQL. Ignorée pour les packs sans tests.
Définit le chemin d’un répertoire dans le pack, contenant les tests (chemin relatif par rapport au répertoire du pack). Utilisez . pour spécifier l’ensemble du pack. Toutes les requêtes de ce répertoire sont exécutées comme tests quand test run est exécuté avec l’option --strict-test-discovery. Ces requêtes sont ignorées par les définitions de suite de requêtes qui utilisent des instructions queries ou qlpack pour demander toutes les requêtes dans un pack particulier. Si cette propriété est manquante, . est utilisé. Par exemple :
```
tests: .
```

`extractor`

Nécessaire pour tous les packs contenant des tests CodeQL.
Définit l’extracteur de langage CodeQL à utiliser pour l’exécution des tests CodeQL dans le pack. Pour plus d’informations sur les tests de requêtes, consultez « Test de requêtes personnalisées ». Par exemple :
```
extractor: javascript
```

`authors`

Optionnel.
Définit les métadonnées qui seront affichées sur la page de recherche relative à l’empaquetage dans la section des packages du compte dans lequel le pack CodeQL est publié. Par exemple :
```
authors: author1@github.com,author2@github.com
```

`license`

Optionnel.
Définit les métadonnées qui seront affichées sur la page de recherche relative à l’empaquetage dans la section des packages du compte dans lequel le pack CodeQL est publié. Pour obtenir la liste des licences autorisées, consultez la liste des licences SPDX dans la spécification SPDX. Par exemple :
```
license: MIT
```

`description`

Optionnel.
Définit les métadonnées qui seront affichées sur la page de recherche relative à l’empaquetage dans la section des packages du compte dans lequel le pack CodeQL est publié. Par exemple :
```
description: Human-readable description of the contents of the CodeQL pack.
```

`libraryPathDependencies`

Facultative, dépréciée. Utilisez plutôt la propriété dependencies.
Précédemment utilisée pour définir les noms des packs CodeQL dont ce pack CodeQL dépend, sous forme de tableau. Elle permet au pack d’accéder à toutes les bibliothèques, à tout schéma de base de données et à toutes les suites de requêtes définis dans la dépendance. Par exemple :
```
libraryPathDependencies: codeql/javascript-all
```

`dbscheme`

Nécessaire pour les packs de langages de base uniquement.
Définit le chemin du schéma de base de données pour toutes les bibliothèques et requêtes écrites pour ce langage CodeQL (consultez l’exemple ci-dessous). Par exemple :
```
dbscheme: semmlecode.python.dbscheme
```

`upgrades`

Nécessaire pour les packs de langages de base uniquement.
Définit le chemin d’un répertoire dans le pack, contenant les scripts de mise à niveau de base de données (chemin relatif par rapport au répertoire du pack). Les mises à niveau de base de données sont utilisées en interne pour garantir qu’une base de données créée avec une version différente de CodeQL CLI est compatible avec la version actuelle de l’interface CLI. Par exemple :
```
upgrades: .
```

`warnOnImplicitThis`

facultatif. La valeur par défaut est false si la propriété warnOnImplicitThis n’est pas définie.
Définit une valeur booléenne qui spécifie si le compilateur doit émettre des avertissements sur les appels de prédicat membres avec des récepteurs d’appels implicites this, c’est-à-dire sans récepteur explicite. Pris en charge à partir de CodeQL CLI versions 2.13.2 et ultérieures. Par exemple :
```
warnOnImplicitThis: true
```

À propos des fichiers `codeql-pack.lock.yml`

Les fichiers codeql-pack.lock.yml stockent les versions des dépendances transitives résolues d’un pack CodeQL. Ce fichier est créé par la commande codeql pack install s’il n’existe pas déjà et doit être ajouté à votre système de gestion de versions. La section dependencies du fichier qlpack.yml contient des plages de versions compatibles avec le pack. Le fichier codeql-pack.lock.yml verrouille les dépendances sur des versions précises. Ceci garantit que quand codeql pack install est exécuté sur ce pack, les mêmes versions des dépendances sont systématiquement récupérées, même si des versions compatibles plus récentes existent.

Par exemple, si un fichier qlpack.yml contient les dépendances suivantes :

dependencies:
  codeql/cpp-all: ^0.1.2
  my-user/my-lib: ^0.2.3
  other-dependency/from-source: "*"

Le contenu du fichier codeql-pack.lock.yml ressemblera à ceci :

dependencies:
  codeql/cpp-all:
    version: 0.1.4
  my-user/my-lib:
    version: 0.2.4
  my-user/transitive-dependency:
    version: 1.2.4

La dépendance codeql/cpp-all est verrouillée sur la version 0.1.4. La dépendance my-user/my-lib est verrouillée sur la version 0.2.4. La dépendance my-user/transitive-dependency, qui est une dépendance transitive et qui n’est pas spécifiée dans le fichier qlpack.yml, est verrouillée sur la version 1.2.4. La dépendance other-dependency/from-source est absente du fichier de verrouillage, car elle est résolue à partir de la source. Cette dépendance doit être disponible dans le même espace de travail CodeQL que le pack. Pour plus d’informations sur les espaces de travail CodeQL et la résolution des dépendances à partir de la source, consultez « À propos des espaces de travail CodeQL ».

Dans la plupart des cas, le fichier codeql-pack.lock.yml est adapté aux packs de requêtes uniquement, car les packs de bibliothèques ne sont pas exécutables et n’ont généralement pas besoin que leurs dépendances transitives soient corrigées. Les packs de bibliothèques contenant des tests font cependant exception. Dans ce cas, le fichier codeql-pack.lock.yml est utilisé afin de garantir que les tests sont toujours exécutés avec les mêmes versions de dépendances pour éviter les faux échecs en cas de disparité des dépendances.

Exemples de packs CodeQL personnalisés

Quand vous écrivez des requêtes ou des tests personnalisés, vous devez les enregistrer dans des packs CodeQL personnalisés. Par souci de simplicité, essayez d’organiser chaque pack logiquement. Pour plus d’informations, consultez « Création et utilisation de packs CodeQL ». Enregistrez les fichiers relatifs aux requêtes et aux tests dans des packs distincts et, si possible, organisez les packs personnalisés dans des dossiers spécifiques pour chaque langage cible. Cette approche est particulièrement utile si vous envisagez de publier vos packs CodeQL pour qu’ils puissent être partagés avec d’autres utilisateurs ou utilisés pour l’analyse du code. Pour plus d’informations, consultez « À propos de l’analyse du code avec CodeQL ».

Packs CodeQL pour les bibliothèques personnalisées

Un pack CodeQL personnalisé contenant des bibliothèques C++ personnalisées sans requête ni test peut avoir un fichier qlpack.yml contenant :

name: my-github-user/my-custom-libraries
version: 1.2.3
library: true
dependencies:
  codeql/cpp-all: ^0.1.2

où codeql/cpp-all est le nom du pack CodeQL pour l’analyse C/C++, inclus dans le dépôt CodeQL. La plage de versions ^0.1.2 indique que ce pack est compatible avec la version 0.1.2 de codeql/cpp-all et toutes les versions supérieures ou toutes les versions inférieures à 0.2.0. Tout fichier de bibliothèque CodeQL (fichier avec extension .qll) défini dans ce pack sera disponible pour les requêtes définies dans n’importe quel pack de requêtes incluant ce pack dans son bloc de dépendances.

La propriété library indique que ce pack est un pack de bibliothèques et qu’il ne contient aucune requête.

Packs CodeQL pour les requêtes personnalisées

Un pack CodeQL personnalisé contenant des requêtes et des bibliothèques C++ personnalisées peut avoir un fichier qlpack.yml contenant :

name: my-github-user/my-custom-queries
version: 1.2.3
dependencies:
  codeql/cpp-all: ^0.1.2
  my-github-user/my-custom-libraries: ^1.2.3
suites: my-custom-suites

où codeql/cpp-all est le nom du pack CodeQL pour l’analyse C/C++, inclus dans le dépôt CodeQL. La plage de versions ^0.1.2 indique que ce pack est compatible avec la version 0.1.2 de codeql/cpp-all et toutes les versions supérieures ou toutes les versions inférieures à 0.2.0. my-github-user/my-custom-libraries est le nom d’un pack CodeQL contenant des bibliothèques CodeQL personnalisées pour C++. Tout fichier de bibliothèque CodeQL (fichier avec extension .qll) défini dans ce pack sera disponible pour les requêtes dans le pack my-github-user/my-custom-queries.

La propriété suites indique un répertoire où se trouvent des suites de requêtes connues. Ces suites peuvent être utilisées sur la ligne de commande en faisant référence à leur nom uniquement et non à leur chemin complet. Pour plus d’informations sur les suites de requêtes, consultez « Création de suites de requêtes CodeQL ».

Packs CodeQL pour les tests personnalisés

Pour les packs CodeQL personnalisés contenant des fichiers de test, vous devez également inclure une propriété extractor pour que la commande test run sache comment créer les bases de données de test. Vous pouvez également spécifier la propriété tests.

Le fichier qlpack.yml suivant indique que my-github-user/my-query-tests dépend de my-github-user/my-custom-queries dont la version est ultérieure ou égale à 1.2.3 et antérieure à 2.0.0. Il déclare également que l’interface CLI doit utiliser l’extracteur (extractor) Java lors de la création de bases de données de test. La ligne tests: . déclare que tous les fichiers .ql du pack doivent être exécutés en tant que tests quand codeql test run est exécuté avec l’option --strict-test-discovery. En général, les packs de test ne contiennent pas de propriété version. Cela vous empêche de les publier accidentellement.

name: my-github-user/my-query-tests
dependencies:
  my-github-user/my-custom-queries: ^1.2.3
extractor: java
tests: .

Pour plus d’informations sur l’exécution des tests, consultez « Test de requêtes personnalisées ».

Exemples de packs CodeQL dans le dépôt CodeQL

Il existe quatre packs CodeQL principaux pour chacun des langages dans le dépôt CodeQL :

Pack de bibliothèques de base pour le langage avec le schéma de base de données utilisé par le langage, les bibliothèques CodeQL et les requêtes sous <language>/ql/lib
Pack de requêtes de base pour le langage, qui inclut les requêtes par défaut pour le langage avec leurs suites de requêtes sous <language>/ql/src
Tests pour les bibliothèques de langages de base et les requêtes sous <language>/ql/test
Exemples de requêtes pour le langage sous <language>/ql/examples

Pack de bibliothèques de base

Voici un exemple de fichier qlpack.yml pour le pack de langages de base des bibliothèques d’analyse C/C++ :

name: codeql/cpp-all
version: x.y.z-dev
dbscheme: semmlecode.cpp.dbscheme
library: true
upgrades: upgrades

Quelques remarques supplémentaires sur les propriétés suivantes :

library : Indique qu’il s’agit d’un pack de bibliothèques sans requêtes exécutables. Il est uniquement destiné à être utilisé comme dépendance pour d’autres packs.
dbscheme et upgrades : Ces propriétés sont internes à CodeQL CLI et doivent être définies uniquement dans le pack QL de base pour un langage.

Pack de requêtes de base

Voici un exemple de fichier qlpack.yml pour le pack de requêtes de base des requêtes d’analyse C/C++ :

name: codeql/cpp-queries
version: x.y.z-dev
dependencies:
    codeql/cpp-all: "*"
    codeql/suite-helpers: "*"
suites: codeql-suites
defaultSuiteFile: codeql-suites/cpp-code-scanning.qls

Quelques remarques supplémentaires sur les propriétés suivantes :

dependencies : Ce pack de requêtes dépend de codeql/cpp-all et codeql/suite-helpers. Étant donné que ces dépendances sont résolues à partir de la source, la version du pack CodeQL avec laquelle elles sont compatibles n’a pas d’importance. Pour plus d’informations sur la résolution des dépendances à partir de la source, consultez « Dépendances sources ».
suites : Indique le répertoire contenant des suites de requêtes connues.
defaultSuiteFile : Nom du fichier de suite de requêtes par défaut utilisé quand aucune suite de requêtes n’est spécifiée.

Tests pour le pack CodeQL de base

Voici un exemple de fichier qlpack.yml pour le pack de tests de base des tests d’analyse C/C++ :

name: codeql/cpp-tests
dependencies:
  codeql/cpp-all: "*"
  codeql/cpp-queries: "*"
extractor: cpp
tests: .

Quelques remarques supplémentaires sur les propriétés suivantes :

dependencies : Ce pack dépend des packs de bibliothèques et de requêtes CodeQL de base pour C++.
extractor : Spécifie que tous les tests utiliseront le même extracteur C++ pour créer la base de données pour les tests.
tests : Spécifie l’emplacement des tests. Dans ce cas, les tests se trouvent dans le dossier racine (et tous les sous-dossiers) du pack.
version : Il n’existe aucune propriété version pour le pack de tests. Ceci empêche la publication accidentelle de packs de tests.

Publication et utilisation de packs CodeQL

Dans cet article