Skip to main content

Cette version de GitHub Enterprise Server ne sera plus disponible le 2024-06-29. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Analyse du code CodeQL pour les langages compilés

Découvrez comment CodeQL analyse les langages compilés, les options de génération disponibles et découvrez comment personnaliser le processus de génération de base de données si nécessaire.

Qui peut utiliser cette fonctionnalité ?

People with write permissions to a repository can configure code scanning for that repository by editing a workflow, when advanced setup is enabled (admin permission is required to change setup).

Code scanning est disponible pour les dépôts appartenant à l’organisation dans GitHub Enterprise Server. Cette fonctionnalité nécessite une licence pour GitHub Advanced Security. Pour plus d’informations, consultez « À propos de GitHub Advanced Security ».

Remarque : Votre administrateur de site doit activer l’code scanning pour votre instance GitHub Enterprise Server afin que vous puissiez utiliser cette fonctionnalité. Si vous souhaitez utiliser GitHub Actions pour analyser votre code, l’administrateur de site doit également activer GitHub Actions et configurer l’infrastructure nécessaire. Pour plus d’informations, consultez « Configuration de l’analyse de code pour votre appliance ».

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

L’Code scanning fonctionne en exécutant des requêtes sur une ou plusieurs bases de données CodeQL. Chaque base de données contient une représentation du code dans un langage unique au sein de votre référentiel. Pour les langages compilés C/C++, C#, Go, et Java, le processus de remplissage de cette base de données implique la génération du code et l’extraction de données.

Le flux de travail de base Workflow d’analyse CodeQL utilise l'action autobuild pour construire votre code. Sinon, vous pouvez désactiver autobuild et spécifier à la place des commandes de build explicites pour analyser uniquement les fichiers générés par ces commandes personnalisées.

Dans GitHub Enterprise Server 3.9, l’installation par défaut ne prend pas en charge les langages compilés. Vous devez donc utiliser la configuration avancée. La configuration avancée génère un fichier de flux de travail que vous pouvez modifier. Les fichiers de flux de travail de démarrage utilisent autobuild pour analyser les langages compilés. Pour plus d’informations, consultez « Définition de la configuration avancée pour l’analyse du code ».

Pour plus d’informations sur les langages, bibliothèques et cadres pris en charge dans la dernière version de CodeQL, consultez «  Langages et cadres pris en charge » dans la documentation CodeQL. Pour plus d’informations sur la configuration requise pour l’exécution de la dernière version de CodeQL, consultez «  Configuration requise » dans la documentation CodeQL.

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

Le flux de travail de base Workflow d’analyse CodeQL utilise l'action autobuild pour construire votre code.

    # Initializes the CodeQL tools for scanning.
    - name: Initialize CodeQL
      uses: github/codeql-action/init@v2
      with:
        languages: ${{ matrix.language }}

    - name: Autobuild
      uses: github/codeql-action/autobuild@v2

À propos de la spécification manuelle des étapes de génération

En cas d’échec de autobuild ou si vous souhaitez analyser un ensemble différent de fichiers source générés par le processus autobuild, vous devez supprimez ou commentez l’étape de génération automatique dans le workflow. Supprimez ensuite les marques de commentaire de l’étape run et spécifiez manuellement le processus de génération à utiliser. Pour C/C++, C#, Go, et Java, CodeQL va analyser 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 votre configuration avancée pour l’analyse du code ».

    # Autobuild attempts to build any compiled languages.
    # - name: Autobuild
    #  uses: github/codeql-action/autobuild@v2

Spécification des commandes de build

Lorsque la génération manuelle est activée, supprimez les marques de commentaire de l’étape run dans le workflow et ajoutez des commandes de génération adaptées à votre référentiel. L’étape run exécute des programmes en ligne de commande avec le shell 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 ».

Spécification de commandes de génération pour plusieurs langages

Pour les référentiels contenant plusieurs langages compilés, vous pouvez spécifier des commandes de génération propres à un langage. Par exemple, si votre référentiel contient C/C++, C# et Java, vous pouvez fournir des étapes de génération manuelles pour un langage (ici Java). Cela spécifie les étapes de génération 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 ».

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 administrateur de site.

Étapes de génération automatique pour les langages compilés

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.

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

Génération de C/C++

Type de système pris en chargeNom système
Système d’exploitationWindows, macOS et Linux
Système de buildWindows : 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.

Autodétection Windows

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).

Autodétection Linux et macOS

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.

Exigences pour l’exécuteur

Pour les exécuteurs autohébergés, vous devrez probablement installer le compilateur gcc et certains projets peuvent également nécessiter un accès à clang ou msvc des exécutables. Vous devez également installer le système de build (par exemplemsbuild, make, cmake, bazel) et les utilitaires (tels que python, perl, lex et yacc) dont dépendent vos projets.

Génération de C#

Type de système pris en chargeNom système
Système d’exploitationWindows, macOS et Linux
Système de build.NET et MSbuild ainsi que les scripts de build

Autodétection Windows

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. Invoquer MSBuild.exe 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. Invoquer un script qui ressemble à un script de génération : build.bat, build.cmd et build.exe (dans cet ordre).

Exigences pour l’exécuteur

Pour le développement d’applications .NET Core sur des exécuteurs auto-hébergés, vous aurez besoin du Kit de développement logiciel (SDK) .NET (pour dotnet).

Pour le développement d’applications .NET Framework, vous aurez besoin de Microsoft Build Tools (pour msbuild) et de l’interface CLI Nuget (pour nuget).

Autodétection Linux et macOS

  1. Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
  2. Invoquer MSbuild 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. Invoquer un script qui ressemble à un script de génération : build et build.sh (dans cet ordre).

Exigences pour l’exécuteur

Pour le développement d’applications .NET Core sur des exécuteurs auto-hébergés, vous aurez besoin du Kit de développement logiciel (SDK) .NET (pour dotnet).

Pour le développement d’applications .NET Framework, vous aurez besoin de runtime Mono (pour exécuter mono, msbuild ou nuget).

Génération de Go

Type de système pris en chargeNom système
Système d’exploitationWindows, macOS et Linux
Système de buildModules Go, dep et Glide, ainsi que des scripts de génération, notamment des scripts Makefiles et Ninja

Détection automatique

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 :

  1. 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.
  2. 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.
  3. 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.
  4. Extrayez tout le code Go dans le dépôt, comme pour l’exécution de go build ./....

Remarque : Si vous utilisez la configuration par défaut, celle-ci recherchera un fichier go.mod pour installer automatiquement une version compatible du langage Go.

Génération de Java et Kotlin

Type de système pris en chargeNom système
Système d’exploitationWindows, macOS et Linux (sans restriction)
Système de buildGradle, Maven et Ant

Détection automatique

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.

Exigences pour l’exécuteur

Si vous utilisez des exécuteurs auto-hébergés, la ou les versions requises de Java doivent être présentes :

  • Si l’exécuteur sera utilisé pour analyser les référentiels qui ont besoin d’une version unique de Java, la version JDK appropriée doit être installée et doit être présente dans la variable PATH (afin que java et javac soient trouvés).

  • Si l’exécuteur sera utilisé pour analyser les référentiels qui ont besoin de plusieurs versions de Java, les versions JDK appropriées doivent être installées et peuvent être spécifiées via le fichier toolchains.xml. Ceci est un fichier de configuration, généralement utilisé par Apache Maven, qui vous permet de spécifier l’emplacement des outils, la version des outils et toute configuration supplémentaire requise pour utiliser les outils. Pour plus d’informations, consultez «  Guide d’utilisation des chaînes d’outils » dans la documentation Apache Maven.

Les exécutables suivants seront probablement requis pour une gamme de projets Java et doivent être présents dans la variable PATH, mais ils ne seront pas essentiels dans tous les cas :

  • mvn (Apache Maven)
  • gradle (Gradle)
  • ant (Apache Ant)

Vous devez également installer le système de build (par exemplemake, cmake, bazel) et les utilitaires (tels que python, perl, lex et yacc) dont dépendent vos projets.