Configuration du workflow CodeQL pour les langages compilés

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

Pour l’code scanning CodeQL, vous pouvez utiliser la configuration par défaut, qui analyse votre code et configure automatiquement votre code scanning, ou la configuration avancée, qui génère un fichier de workflow que vous pouvez modifier. Pour le moment, la configuration par défaut ne prend en charge aucun langage compilé. Vous devez donc utiliser la configuration avancée. 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#, Go, Kotlin 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#, Go, Kotlin 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.

Remarque : Si vous utilisez des exécuteurs auto-hébergés pour GitHub Actions, vous devrez peut-être installer des logiciels supplémentaires pour utiliser le processus autobuild. En outre, si votre dépôt nécessite une version spécifique d’un outil de génération, vous devrez peut-être l’installer manuellement. Pour plus d’informations, consultez « À propos des exécuteurs hébergés par GitHub ».

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 :

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.
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é :

Rechercher un système de build dans le répertoire racine.
Si aucun répertoire n’est trouvé, rechercher un répertoire unique avec un système de build pour C/C++.
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 :

Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
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.
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).

Go

Type de système pris en charge	Nom système
Système d’exploitation	Windows, macOS et Linux
Système de build	Modules Go, `dep` et Glide, ainsi que des scripts de génération, notamment des scripts Makefiles et Ninja

Le processus autobuild tente de détecter automatiquement un moyen approprié d’installer les dépendances dont un dépôt Go a besoin avant d’extraire tous les fichiers .go :

Appelez make, ninja, ./build ou ./build.sh (dans cet ordre) jusqu’à ce que l’une de ces commandes réussisse et qu’une commande go list ./... ultérieure réussisse également, indiquant que les dépendances nécessaires ont été installées.
Si aucune de ces commandes ne réussit, recherchez go.mod, Gopkg.toml ou glide.yaml, et exécutez go get (sauf si le vendoring est utilisé), dep ensure -v ou glide install respectivement pour essayer d’installer les dépendances.
Enfin, si les fichiers de configuration de ces gestionnaires de dépendances sont introuvables, réorganisez la structure de répertoires du dépôt pour l’ajouter à GOPATH et utilisez go get pour installer les dépendances. La structure de répertoires revient à la normale une fois l’extraction terminée.
Extrayez tout le code Go dans le dépôt, comme pour l’exécution de go build ./....

Java et Kotlin

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 :

Rechercher un fichier de build dans le répertoire racine. Rechercher les fichiers de build Gradle, puis Maven, puis Ant.
Exécuter le premier fichier de build trouvé. Si les fichiers Gradle et Maven sont présents, le fichier Gradle est utilisé.
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.

Swift

Type de système pris en charge	Nom système
Système d’exploitation	macOS
Système de build	Xcode

Le processus autobuild tente de générer la plus grande cible à partir d’un projet ou d’un espace de travail Xcode.

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, Kotlin, Java et Swift, 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 configuration avancée de 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 le support GitHub.

Considérations relatives à la génération de code Swift

Remarques :

L’analyse CodeQL pour Swift est en version bêta. Pour la version bêta, l’analyse du code Swift et la documentation associée ne seront pas aussi complètes que pour les autres langages. Swift 5.8 n’est pas encore pris en charge.
L’analyse peut parfois se figer, ce qui entraîne l’expiration du délai d’attente des travaux. Pour limiter le nombre de minutes Actions utilisées par les travaux bloqués ou arrivant à expiration, nous vous recommandons de définir un délai d’expiration égal à quatre fois le temps de génération normal.

L’analyse du code Swift utilise des exécuteurs macOS par défaut. Étant donné que les exécuteurs macOS hébergés par GitHub sont plus coûteux que les exécuteurs Linux et Windows, nous vous recommandons de générer uniquement le code que vous souhaitez analyser. Pour plus d’informations sur les tarifs des exécuteurs hébergés par GitHub, consultez « À propos de la facturation de GitHub Actions ».

xcodebuild et swift build sont tous deux pris en charge pour les builds Swift. Nous vous recommandons de cibler une seule architecture pendant la génération. Par exemple, ARCH=arm64 pour xcodebuild, ou --arch arm64 pour swift build.

Vous pouvez passer les options archive et test à xcodebuild. Toutefois, la commande standard xcodebuild est recommandée, car elle doit être la plus rapide et doit être tout ce que CodeQL nécessite pour une analyse réussie.

Pour l’analyse Swift, vous devez toujours installer explicitement les dépendances gérées via CocoaPods ou Carthage avant de générer la base de données CodeQL.

Configuration du workflow CodeQL pour les langages compilés

Dans cet article