Configuration du workflow CodeQL pour les langages compilés

À propos du Workflow d’analyse CodeQL et des langages compilés

Vous configurez GitHub afin d’exécuter l’code scanning pour votre dépôt en ajoutant un workflow GitHub Actions à ce dernier. Pour l’code scanning CodeQL, vous ajoutez le Workflow d’analyse CodeQL. Pour plus d’informations, consultez « Configuration de l’analyse du code pour un référentiel ».

En règle générale, vous n’avez pas besoin de modifier le fichier de workflow généré pour code scanning. Toutefois, si nécessaire, vous pouvez modifier le workflow pour personnaliser certains paramètres. Par exemple, vous pouvez modifier Workflow d’analyse CodeQL de GitHub pour spécifier la fréquence des analyses, les langages ou les répertoires à analyser, et ce que CodeQL code scanning recherche dans votre code. Vous risquez aussi de devoir modifier le Workflow d’analyse CodeQL si vous utilisez un ensemble spécifique de commandes pour compiler votre code. Pour obtenir des informations générales sur la configuration de l’code scanning et la modification des fichiers de workflow, consultez « Personnalisation de l’analyse du code » et « Découvrir GitHub Actions ».

À propos de la génération automatique pour CodeQL

L’Code scanning fonctionne en exécutant des requêtes sur une ou plusieurs bases de données. Chaque base de données contient une représentation de tout le code dans un langage unique au sein de votre dépôt. Pour les langages compilés C/C++, C#, et Java, le processus de remplissage de cette base de données implique la génération du code et l’extraction des données. Pour ces langages, CodeQL analyse les fichiers sources générés dans votre dépôt. Pour ces langages, vous pouvez désactiver autobuild et utiliser à la place des commandes de build personnalisées afin d’analyser uniquement les fichiers générés par ces commandes personnalisées.

Pour les langages compilés pris en charge, vous pouvez utiliser l’action autobuild dans le Workflow d’analyse CodeQL pour générer votre code. Cela vous évite d’avoir à spécifier des commandes de build explicites pour C/C++, C#, et Java.

Si votre workflow utilise une matrice language, autobuild tente de générer chacun des langages compilés listés dans la matrice. Sans matrice, autobuild tente de générer le langage compilé pris en charge qui a le plus grand nombre de fichiers sources dans le dépôt. À l’exception de Go, l’analyse d’autres langages compilés dans votre dépôt échoue, sauf si vous fournissez des commandes de build explicites.

C/C++

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux
Système de build	Windows : scripts MSbuild et de build Linux et macOS : Autoconf, Make, CMake, qmake, Meson, Waf, SCons, Linux Kbuild et scripts de build

Le comportement de l’étape autobuild varie en fonction du système d’exploitation sur lequel l’extraction s’exécute. Sur Windows, l’étape autobuild tente de détecter automatiquement une méthode de génération appropriée pour C/C++ en utilisant l’approche suivante :

1. Appeler MSBuild.exe sur le fichier solution (.sln) ou projet (.vcxproj) le plus proche de la racine. Si autobuild détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.
2. Appeler un script qui ressemble à un script de build : build.bat, build.cmd et build.exe (dans cet ordre).

Sur Linux et macOS, l’étape autobuild passe en revue les fichiers présents dans le dépôt pour déterminer le système de build utilisé :

1. Rechercher un système de build dans le répertoire racine.
2. Si aucun répertoire n’est trouvé, rechercher un répertoire unique avec un système de build pour C/C++.
3. Exécuter une commande appropriée pour configurer le système.

C#

Type de système pris en charge	Nom système
Système d’exploitation	Windows et Linux
Système de build	.NET et MSbuild ainsi que les scripts de build

Le processus autobuild tente de détecter automatiquement une méthode de génération appropriée pour C# en utilisant l’approche suivante :

1. Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
2. Appeler MSbuild (Linux) ou MSBuild.exe (Windows) sur le fichier solution ou projet le plus proche de la racine. Si autobuild détecte plusieurs fichiers solution ou projet à la même profondeur (la plus courte) à partir du répertoire de niveau supérieur, il tente de les générer tous.
3. Appeler un script qui ressemble à un script de build : build et build.sh (dans cet ordre, pour Linux) ou build.bat, build.cmd et build.exe (dans cet ordre, pour Windows).

Java

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux (sans restriction)
Système de build	Gradle, Maven et Ant

Le processus autobuild tente de déterminer le système de build pour les codebases Java en appliquant cette stratégie :

1. Rechercher un fichier de build dans le répertoire racine. Rechercher les fichiers de build Gradle, puis Maven, puis Ant.
2. Exécuter le premier fichier de build trouvé. Si les fichiers Gradle et Maven sont présents, le fichier Gradle est utilisé.
3. Sinon, rechercher les fichiers de build dans les sous-répertoires directs du répertoire racine. Si un seul sous-répertoire contient des fichiers de build, exécutez le premier fichier identifié dans ce sous-répertoire (en utilisant la même préférence que pour 1). Si plusieurs sous-répertoires contiennent des fichiers de build, signaler une erreur.

Ajout des étapes de build pour un langage compilé

Si autobuild échoue, ou si vous voulez analyser un ensemble de fichiers sources différents de ceux générés par le processus autobuild, vous devez supprimer l’étape autobuild du workflow et ajouter manuellement les étapes de génération. Pour les projets C/C++, C#, Go, et Java, CodeQL analyse le code source généré par vos étapes de génération spécifiées. Pour plus d’informations sur la modification du fichier de workflow, consultez « Personnalisation de l’analyse du code ».

Après avoir supprimé l’étape autobuild, supprimez les marques de commentaire de l’étape run et ajoutez des commandes de build qui conviennent à votre dépôt. L’étape run du workflow exécute des programmes en ligne de commande avec l’interpréteur de commandes du système d’exploitation. Vous pouvez modifier ces commandes et ajouter d’autres commandes pour personnaliser le processus de build.

- run: |
    make bootstrap
    make release

Pour plus d’informations sur le mot clé run, consultez « Workflow syntax for GitHub Actions ».

Si votre référentiel contient plusieurs langages compilés, vous pouvez spécifier des commandes de build spécifiques à un langage. Par exemple, si votre dépôt contient du code C/C++, C# et Java et que autobuild génère correctement le code C/C++ et C#, mais ne parvient pas à générer le code Java, vous pouvez utiliser la configuration suivante dans votre workflow, après l’étape init. Cela spécifie les étapes de build pour Java tout en continuant à utiliser autobuild pour C/C++ et C# :

- if: matrix.language == 'cpp' || matrix.language == 'csharp'
  name: Autobuild
  uses: github/codeql-action/autobuild@v2

- if: matrix.language == 'java'
  name: Build Java
  run: |
    make bootstrap
    make release

Pour plus d’informations sur le conditionnel if, consultez « Workflow syntax for GitHub Actions ».

Pour obtenir d’autres conseils et astuces sur la raison pour laquelle autobuild ne génère pas votre code, consultez « Résolution des problèmes de workflow CodeQL ».

Si vous avez ajouté des étapes de génération manuelles pour les langages compilés et que l’code scanning ne fonctionne toujours pas sur votre dépôt, contactez le votre propriétaire d’entreprise.