Ă propos des espaces de travail CodeQL
Remarque
Cet article dĂ©crit les fonctionnalitĂ©s disponibles avec la version de lâaction CodeQL et le pack CodeQL CLI associĂ© inclus dans la mise en production initiale de cette version de GitHub Enterprise Server. Si votre entreprise utilise une version plus rĂ©cente de lâaction CodeQL, consultez la version GitHub Enterprise Cloud de cet article pour obtenir plus dâinformations sur les derniĂšres fonctionnalitĂ©s. Pour plus dâinformations sur lâutilisation de la derniĂšre version, consultez Configuration de lâanalyse de code pour votre appliance.
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.