Skip to main content

À propos des espaces de travail CodeQL

Les espaces de travail CodeQL vous permettent de développer et de gérer un groupe de packs CodeQL qui dépendent les uns des autres.

Qui peut utiliser cette fonctionnalité ?

CodeQL est disponible pour les types de rĂ©fĂ©rentiels suivants :

À propos des espaces de travail CodeQL

Vous utilisez un espace de travail CodeQL quand vous voulez regrouper plusieurs packs CodeQL ensemble. Un cas d’usage classique pour un espace de travail CodeQL consiste Ă  dĂ©velopper un ensemble de bibliothĂšques et de packs de requĂȘtes CodeQL qui dĂ©pendent les uns des autres. Pour plus d’informations sur les packs CodeQL, consultez Personnalisation de l’analyse avec des packs CodeQL.

Le principal avantage d’un espace de travail CodeQL est qu’il vous permet de dĂ©velopper et de gĂ©rer plus facilement plusieurs packs CodeQL. Quand vous utilisez un espace de travail CodeQL, tous les packs CodeQL de l’espace de travail sont disponibles sous forme de dĂ©pendances sources les uns pour les autres quand vous exĂ©cutez une commande CodeQL qui rĂ©sout des requĂȘtes. Le dĂ©veloppement, la gestion et la publication de plusieurs packs CodeQL associĂ©s sont ainsi facilitĂ©s.

Dans la plupart des cas, il est prĂ©fĂ©rable de stocker l’espace de travail CodeQL et les packs CodeQL qu’il contient dans un seul dĂ©pĂŽt Git. Le partage de votre environnement de dĂ©veloppement CodeQL s’en retrouve ainsi facilitĂ©.

Le fichier codeql-workspace.yml

Un espace de travail CodeQL est défini par un fichier yaml codeql-workspace.yml. Ce fichier contient un bloc provide et éventuellement des blocs ignore et registries.

  • Le bloc provide contient la liste des modĂšles Glob qui dĂ©finissent les packs CodeQL disponibles dans l’espace de travail.

  • Le bloc ignore contient la liste des modĂšles Glob qui dĂ©finissent les packs CodeQL non disponibles dans l’espace de travail.

  • Le bloc registries contient la liste des URL GHES et des modĂšles de package qui contrĂŽlent le registre de conteneurs utilisĂ© pour la publication des packs CodeQL. Pour plus d’informations, consultez « Publication et utilisation de packs CodeQL Â».

Chaque entrĂ©e de la section provide ou ignore doit correspondre Ă  l’emplacement d’un fichier qlpack.yml. Tous les modĂšles Glob sont dĂ©finis par rapport au rĂ©pertoire qui contient le fichier d’espace de travail. Pour obtenir la liste des modĂšles acceptĂ©s dans ce fichier, consultez @actions/glob.

Par exemple, le fichier codeql-workspace.yml suivant dĂ©finit un espace de travail qui contient tous les packs CodeQL trouvĂ©s de maniĂšre rĂ©cursive dans le rĂ©pertoire codeql-packs, Ă  l’exception des packs inclus dans le rĂ©pertoire experimental. Le bloc registries spĂ©cifie que les packs codeql/\* doivent ĂȘtre tĂ©lĂ©chargĂ©s Ă  partir de https://ghcr.io/v2/, Ă  savoir le registre de conteneurs par dĂ©faut de GitHub. Tous les autres packs doivent ĂȘtre tĂ©lĂ©chargĂ©s depuis le registre situĂ© Ă  l’adresse GHE_HOSTNAME et publiĂ©s sur celui-ci.

provide:
  - "*/codeql-packs/**/qlpack.yml"
ignore:
  - "*/codeql-packs/**/experimental/**/qlpack.yml"

registries:
 - packages: 'codeql/*'
   url: https://ghcr.io/v2/

 - packages: '*'
   url: https://containers.GHE_HOSTNAME/v2/

Pour vĂ©rifier que votre fichier codeql-workspace.yml inclut les packs CodeQL attendus, exĂ©cutez la commande codeql pack ls dans le mĂȘme rĂ©pertoire que votre espace de travail. Le rĂ©sultat de la commande est la liste de tous les packs CodeQL inclus dans l’espace de travail.

Dépendances sources

Les dĂ©pendances sources sont des packs CodeQL rĂ©solus Ă  partir du systĂšme de fichiers local en dehors du cache des packages CodeQL. Ces dĂ©pendances peuvent se trouver dans le mĂȘme espace de travail CodeQL ou ĂȘtre spĂ©cifiĂ©es sous forme d’option de chemin Ă  l’aide de l’argument --additional-packs. Quand vous compilez et exĂ©cutez des requĂȘtes localement, les dĂ©pendances sources remplacent toutes les dĂ©pendances trouvĂ©es dans le cache des packages CodeQL ainsi que les contraintes de version dĂ©finies dans le fichier qlpack.yml. Toutes les rĂ©fĂ©rences aux packs CodeQL dans le mĂȘme espace de travail sont rĂ©solues en dĂ©pendances sources.

Cela s’avĂšre particuliĂšrement utile dans les situations suivantes :

  • L’une des dĂ©pendances du pack de requĂȘtes que vous exĂ©cutez n’est pas encore publiĂ©e. La rĂ©solution Ă  partir de la source est la seule façon de rĂ©fĂ©rencer ce pack.

  • Vous apportez des modifications Ă  plusieurs packs en mĂȘme temps et vous voulez les tester ensemble. La rĂ©solution Ă  partir de la source garantit que vous utilisez la version du pack qui contient vos modifications.

RĂ©solution des requĂȘtes et espaces de travail CodeQL

Tous les packs CodeQL inclus dans un espace de travail sont disponibles en tant que dĂ©pendances sources les uns pour les autres quand vous exĂ©cutez une commande CodeQL qui rĂ©sout des requĂȘtes ou des packs. Par exemple, quand vous exĂ©cutez codeql pack install dans le rĂ©pertoire d’un pack dans un espace de travail, toute dĂ©pendance qui se trouve dans l’espace de travail est utilisĂ©e au lieu de tĂ©lĂ©charger cette dĂ©pendance dans le cache du package et de l’ajouter au fichier codeql-pack.lock.yml. Pour plus d’informations, consultez « CrĂ©ation et utilisation de packs CodeQL Â».

De mĂȘme, lorsque vous publiez un CodeQL query pack dans le registre de conteneurs GitHub en utilisant la commande codeql pack publish utilisera toujours les dĂ©pendances de l'espace de travail au lieu d'utiliser les dĂ©pendances trouvĂ©es dans le cache local des paquets.

Cela garantit que toutes les modifications locales que vous apportez Ă  une bibliothĂšque de requĂȘtes dans une dĂ©pendance sont automatiquement rĂ©percutĂ©es dans les packs de requĂȘtes que vous publiez Ă  partir de cet espace de travail.

Exemple

Examinons le fichier codeql-workspace.yml suivant :

provide:
  - "**/qlpack.yml"

Et le fichier qlpack.yml du pack de bibliothĂšques CodeQL suivant dans l’espace de travail :

name: my-company/my-library
library: true
version: 1.0.0

Et le fichier qlpack.yml du pack de requĂȘtes CodeQL suivant dans l’espace de travail :

name: my-company/my-queries
version: 1.0.0
dependencies:
  my-company/my-library: "*"
  codeql/cpp-all: ~0.2.0

Remarquez que le bloc dependencies pour le pack de requĂȘtes CodeQL, my-company/my-queries, spĂ©cifie "*" comme version du pack de bibliothĂšques. Étant donnĂ© que le pack de bibliothĂšques est dĂ©jĂ  dĂ©fini en tant que dĂ©pendance source dans codeql-workspace.yml, le contenu du pack de bibliothĂšques est toujours rĂ©solu Ă  partir de l’espace de travail. Toute contrainte de version que vous dĂ©finissez est ignorĂ©e dans ce cas. Nous vous recommandons d’utiliser "*" pour les dĂ©pendances sources afin de bien montrer que la version est hĂ©ritĂ©e de l’espace de travail.

Quand vous exĂ©cutez codeql pack install Ă  partir du rĂ©pertoire du pack de requĂȘtes, une version appropriĂ©e de codeql/cpp-all est tĂ©lĂ©chargĂ©e dans le cache du package local. De plus, un fichier codeql-pack.lock.yml contenant la version rĂ©solue de codeql/cpp-all est créé. Le fichier de verrouillage ne contient pas d’entrĂ©e pour my-company/my-library, car il est rĂ©solu Ă  partir de dĂ©pendances sources. Le fichier codeql-pack.lock.yml va ressembler Ă  ceci :

dependencies:
  codeql/cpp-all:
    version: 0.2.2

Quand vous exĂ©cutez codeql pack publish Ă  partir du rĂ©pertoire du pack de requĂȘtes, la dĂ©pendance codeql/cpp-all du cache du package et la bibliothĂšque my-company/my-library de l’espace de travail sont regroupĂ©es avec my-company/my-queries et publiĂ©es dans le registre de conteneurs GitHub.

Utilisation de ${workspace} en tant que plage de versions dans les fichiers qlpack.yml

CodeQL packs dans un espace de travail peuvent utiliser les espaces rĂ©servĂ©s spĂ©ciaux ${workspace}, ~${workspace}et ^${workspace} de plage de versions. Ces espaces rĂ©servĂ©s indiquent que ce pack dĂ©pend de la version du pack spĂ©cifiĂ© qui se trouve actuellement dans l’espace de travail. Cet espace rĂ©servĂ© est gĂ©nĂ©ralement utilisĂ© pour les dĂ©pendances Ă  l’intĂ©rieur des packs de bibliothĂšque afin de s’assurer que lorsqu’ils sont publiĂ©s. Les dĂ©pendances dans leur fichier qlpack.yml reflĂštent l’état de l’espace de travail lorsqu’ils ont Ă©tĂ© publiĂ©s.

Exemple

Tenez compte des deux packs de bibliothĂšque suivants dans le mĂȘme espace de travail :

name: my-company/my-library
library: true
version: 1.2.3
dependencies:
  my-company/my-library2: ${workspace}
name: my-company/my-library2
library: true
version: 4.5.6

Lorsque my-company/my-library est publié dans le registre de conteneurs GitHub, la version de la dépendance my-company/my-library2 dans le fichier qlpack.yml publié est écrite en tant que 4.5.6.

De mĂȘme, si la dĂ©pendance est my-company/my-library2: ^${workspace} dans le pack source, puis que le pack est publiĂ©, la version de la my-company/my-library2 dĂ©pendance dans le fichier qlpack.yml publiĂ© est Ă©crite en tant que ^4.5.6, indiquant que les versions >= 4.5.6 et < 5.0.0 sont toutes compatibles avec ce pack de bibliothĂšque.

Si la dépendance est my-company/my-library2: ~${workspace} dans le pack source, puis que le pack est ensuite publié, la version de la dépendance my-company/my-library2 dans le fichier qlpack.yml publié est écrite en tant que ~4.5.6, indiquant que les versions >= 4.5.6 et < 4.6.0 sont toutes compatibles avec ce pack de bibliothÚque.