Analyse CodeQL pour les langages compilés

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

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 seul langage au sein de votre dépôt. Pour les langages compilés C/C++, C#, Go, Java, Kotlin, Rust (préversion publique), et Swift, le processus de remplissage de cette base de données implique souvent de compiler le code et d’extraire des données.

Lorsque vous activez code scanning, la configuration par défaut et la configuration avancée génèrent une base de données CodeQL à analyser en utilisant la méthode la plus simple disponible. Pour C# et Java, la base de données CodeQL est générée directement à partir de la base de code sans nécessiter de build (mode de build none). Pour les autres langages compilés, CodeQL compile la base de code à l’aide du mode de build autobuild. Vous pouvez également utiliser le mode de build manual pour spécifier des commandes de build explicites afin d’analyser uniquement les fichiers compilés par ces commandes personnalisées.

Vous pouvez utiliser la mise en cache des dépendances avec CodeQL pour stocker les dépendances comme un cache GitHub Actions au lieu de les télécharger depuis les registres. Pour plus d’informations, consultez À propos de la mise en cache des dépendances pour CodeQL plus loin dans cet article.

Modes de build de CodeQL

L’action CodeQL prend en charge trois modes de build différents pour les langages compilés :

•         `none` : la base de données CodeQL est créée directement à partir de la base de code sans compiler celle-ci (pris en charge pour tous les langages interprétés, et également pour C# et  Java).
  

•           `autobuild` : CodeQL détecte la méthode de build la plus probable et tente de l’utiliser pour compiler la base de code et créer une base de données pour l’analyse (pris en charge pour C/C++, C#, Go, Java, Kotlin et Swift).
  

•           `manual` : vous définissez les étapes de build à utiliser pour la base de code dans le workflow (pris en charge pour C/C++, C#, Go, Java, Kotlin et Swift).
  

Comparaison des modes de build

Recommendations

Lorsque vous configurez code scanning pour la première fois, ou sur plusieurs dépôts, il est préférable d’utiliser la configuration par défaut. La configuration par défaut utilise la méthode la plus simple disponible pour générer une base de données CodeQL et analyser votre code, afin que vous puissiez commencer à corriger les alertes le plus rapidement possible. Une fois les alertes initiales résolues, vous pourrez envisager de passer à la configuration avancée avec un processus de build manuel pour les dépôts à haut risque.

Utilisation de plusieurs modes de build dans un dépôt multilangage

Pour les dépôts comportant plusieurs langages compilés, vous pouvez utiliser des modes de build différents selon le langage. Par exemple, si votre dépôt contient du C/C++, du C# et du Java, vous pourriez vouloir fournir des étapes de build manuelles pour un langage (ici le C/C++). Ce workflow spécifie un mode de build différent pour chaque langage.

strategy:
  matrix:
    include:
      # Analyzes C and C++ code using the commands in `Build C and C++ code`
      - language: c-cpp
        build-mode: manual
      # Analyzes C# code by automatically detecting a build
      - language: csharp
        build-mode: autobuild
      # Analyzes Java code directly from the codebase without a build
      - language: java-kotlin
        build-mode: none # analyzes Java only
steps:
- name: Checkout repository
  uses: actions/checkout@v5

# Initializes CodeQL tools and creates a codebase for analysis.
- name: Initialize CodeQL
  uses: github/codeql-action/init@v4
  with:
    languages: ${{ matrix.language }}
- if: ${{ matrix.build-mode == 'manual' }}
  name: Build C and C++ code
  run: |
    echo 'If you are using a "manual" build mode for one or more of the' \
      'languages you are analyzing, replace this with the commands to build' \
      'your code, for example:'
    echo ' make bootstrap'
    echo ' make release'
    exit 1

Pour des informations sur les langages, bibliothèques et frameworks pris en charge dans la dernière version de CodeQL, consultez Langages et frameworks pris en charge dans la documentation CodeQL. Pour des informations sur la configuration système requise pour exécuter la dernière version de CodeQL, consultez Configuration système requise dans la documentation CodeQL.

À propos de la mise en cache des dépendances pour CodeQL

Vous pouvez utiliser la mise en cache des dépendances avec CodeQL pour stocker les dépendances comme un cache GitHub Actions au lieu de les télécharger depuis les registres. Cela réduit le risque de perdre des alertes lorsque les registres tiers fonctionnent mal, et peut améliorer les performances des projets ayant un grand nombre de dépendances ou utilisant des registres lents. Pour en savoir plus sur la façon dont la mise en cache des dépendances peut accélérer les workflows, consultez Référence sur la mise en cache des dépendances.

La mise en cache des dépendances fonctionne avec tous les modes de build et est prise en charge par Java, Go, et C#.

Activation de la mise en cache des dépendances pour CodeQL

Pour les workflows de configuration par défaut, la mise en cache des dépendances n’est activée que pour les runners hébergés par GitHub dans les dépôts publics et privés.

Pour les workflows de configuration avancée, la mise en cache des dépendances est désactivée par défaut. Pour activer la mise en cache des dépendances pour CodeQL, utilisez le paramètre dependency-caching de l’action CodeQL dans votre workflow de configuration avancée. Ce paramètre accepte les valeurs suivantes :

•         `false`
          /
          `none`
          /
          `off` : la mise en cache des dépendances est désactivée (par défaut)
  

•         `restore` : restaurer uniquement les caches existants, ne pas stocker de nouveaux caches
  

•         `store` : stocker uniquement de nouveaux caches, ne pas restaurer de caches
  

•         `true`
          /
          `full`
          /
          `on` : restaurer les caches existants et stocker de nouveaux caches
  

Par exemple, les paramètres suivants activeraient la mise en cache des dépendances pour l’action CodeQL :

    # Initializes CodeQL with dependency caching enabled
    - name: Initialize CodeQL
      uses: github/codeql-action/init@v4
      with:
        languages: java
        dependency-caching: true

À propos du mode de build None pour CodeQL

Pour C# et Java, CodeQL crée une base de données sans nécessiter de build lorsque vous activez la configuration par défaut de code scanning, sauf si le dépôt contient également du code Kotlin. Si un dépôt contient du code Kotlin en plus du code Java, la configuration par défaut est activée avec le processus autobuild, car l’analyse Kotlin nécessite un build.

La création d’une base de données CodeQL sans build peut produire des résultats moins précis que l’utilisation du autobuild ou d’étapes de build manuelles si :

• Les scripts de build ne peuvent pas être interrogés pour obtenir des informations sur les dépendances et les déductions de dépendances sont inexactes.
• Le dépôt génère normalement du code pendant le processus de build.

Pour utiliser le autobuild ou des étapes de build manuelles, vous pouvez utiliser la configuration avancée.

À propos d’Autobuild pour CodeQL

L’action CodeQL utilise autobuild pour analyser les langages compilés dans les cas suivants :

• La configuration par défaut est activée et le langage ne prend pas en charge le build none (pris en charge pour C# et Java).
• La configuration avancée est activée et le workflow spécifie build-mode: autobuild.
• La configuration avancée est activée et le workflow comporte une étape Autobuild pour le langage utilisant l’action autobuild (github/codeql-action/autobuild@v4).

Exemple utilisant l’option build-mode

# Initializes the CodeQL tools for scanning.
name: Analyze
strategy:
  matrix:
    include:
      # Analyze C and C++ code
      - language: c-cpp
        build-mode: autobuild
      # Analyze Go code
      - language: go
        build-mode: autobuild

steps:
  - uses: github/codeql-action/init@v4
    with:
      languages: ${{ matrix.language }}
      build-mode: ${{ matrix.build-mode }}

Exemple utilisant l’étape Autobuild

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

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

À propos de la spécification manuelle des étapes de build

Vous ne pouvez spécifier des étapes de build manuelles que si vous avez activé la configuration avancée ; consultez Configuration avancée de l’analyse du code.

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 effectuer les opérations suivantes :

• Si votre flux de travail spécifie un mode de génération pour la langue, remplacez le mode de génération par manual.
• Si votre flux de travail contient une étape autobuild, supprimez ou commentez l’étape autobuild dans le flux de travail.

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, Java, Kotlin et Swift, CodeQL analysera le code source construit par les étapes de construction spécifiées. Pour plus d’informations sur la modification du fichier de workflow, consultez Personnalisation de votre configuration avancée pour l’analyse de code.

Mettez à jour votre workflow afin de définir le build-mode sur manual.

# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
- uses: github/codeql-action/init@v4
  with:
    languages: ${{ matrix.language }}
    build-mode: manual
- uses: github/codeql-action/analyze@v4
  with:
    category: "/language:${{ matrix.language }}"

Vous pouvez également mettre à jour votre workflow pour commenter l’étape « Autobuild ».

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

Spécification des commandes de build

Lorsque la compilation manuelle est activée, décommentez l’étape run dans le workflow et ajoutez des commandes de build adaptées à votre dépôt. L’étape run exécute des programmes en ligne de commande à l’aide du 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 Syntaxe de flux de travail pour 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 Autobuild pour les langages compilés

Si vous utilisez des runners 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 les runners auto-hébergés, vous devez installer les dépendances directement sur les runners eux-mêmes. Nous fournissons des exemples de dépendances courantes pour C/C++, C# et Java dans chacune des sections autobuild de cet article pour ces langages. Pour plus d’informations, consultez Exécuteurs auto-hébergés.

•         [Compiler C/C++](#building-cc)
  

•         [Compiler C#](#building-c)
  

•         [Compiler Go](#building-go)
  

•         [Construction de Java et Kotlin](#building-java-and-kotlin) 
  

•         [Compiler Swift](#building-swift)
  

Compiler C/C++

CodeQL prend en charge les modes de build autobuild ou manual pour le code C/C++.

Résumé d’Autobuild pour C/C++

Type de système pris en charge	Nom du 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.

Détection automatique 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).

Détection automatique 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 relatives au runner pour C/C++

Sur les runners Ubuntu Linux, autobuild peut tenter d’installer automatiquement les dépendances requises par la configuration et les étapes de build détectées. Par défaut, ce comportement est activé sur les runners hébergés par GitHub et désactivé sur les runners auto-hébergés. Vous pouvez activer ou désactiver explicitement cette fonctionnalité en définissant CODEQL_EXTRACTOR_CPP_AUTOINSTALL_DEPENDENCIES sur true ou false dans l’environnement. Pour plus d’informations sur la définition de variables d’environnement, consultez Stocker des informations dans des variables.

Pour les runners auto-hébergés, sauf si l’installation automatique des dépendances est activée, vous devrez probablement installer le compilateur gcc, et certains projets peuvent également nécessiter l’accès aux exécutables clang ou msvc. Vous devrez également installer le système de build (par exemple msbuild, make, cmake, bazel) ainsi que les utilitaires (tels que python, perl, lex et yacc) dont vos projets dépendent. Si vous activez l’installation automatique des dépendances, vous devez vous assurer que le runner utilise Ubuntu et qu’il peut exécuter sudo apt-get sans nécessiter de mot de passe.

Les runners Windows exigent que powershell.exe soit présent dans le PATH.

Compiler C#

CodeQL prend en charge les modes de build none, autobuild ou manual pour le code C#.

Lorsque vous activez la configuration par défaut pour un dépôt contenant du code C#, le mode de build est automatiquement défini sur none.

Analyse sans build pour C#

CodeQL restaure les dépendances et génère quelques fichiers source supplémentaires pour obtenir des résultats plus précis, avant de créer une base de données à partir de tous les fichiers source et de toutes les dépendances.

Les dépendances sont restaurées à l’aide de plusieurs heuristiques et stratégies. Les fichiers suivants constituent les principales sources d’information : *.csproj, *.sln, nuget.config, packages.config, global.json et project.assets.json.

Les fichiers source générés suivants sont optionnels, mais augmentent significativement la justesse de la base de données CodeQL :

•           directives `global``using` générées pour gérer la fonctionnalité implicite `using` de MSbuild.
  

• Fichiers de vues ASP.NET Core : les fichiers .cshtml sont convertis en fichiers .cs.

Les informations issues des noms d’assembly de dépendances, des fichiers source générés, et des fichiers source du dépôt sont compilées et utilisées pour créer une base de données CodeQL.

Précision de l’analyse sans build pour C#

La création d’une base de données CodeQL sans compiler l’intégralité du code repose sur la capacité à restaurer les dépendances et à compiler ensemble les fichiers source présents dans le dépôt. Lorsque des problèmes surviennent lors de la restauration des dépendances ou de la compilation du code source, cela peut affecter la précision de la base de données CodeQL et les résultats de l’analyse code scanning.

Vous pouvez garantir une analyse plus précise en suivant les étapes suivantes :

• Fournissez un accès à l’internet public ou assurez-vous que l’accès à un flux NuGet privé est disponible.
• Vérifiez si le dépôt requiert plusieurs versions d’une même dépendance NuGet. CodeQL ne peut utiliser qu’une seule version et choisit généralement la plus récente lorsqu’il existe plusieurs versions. Cette approche peut ne pas convenir à tous les dépôts.
• Vérifiez si plusieurs versions de .NET sont référencées, par exemple net48, net5.0 et netstandard1.6. CodeQL ne peut utiliser qu’une seule version, ce qui peut affecter la précision.
• Évitez les collisions de noms de classes, sinon cela peut entraîner l’absence de cibles d’appel de méthode, ce qui a un impact sur l’analyse de flux de données.

Résumé d’Autobuild pour C#

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

Détection automatique 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. Appeler MSBuild.exe sur le fichier de solution ou de 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 ressemblant à un script de build —build.bat, build.cmd et build.exe (dans cet ordre).

Exigences relatives au runner pour C# sous Windows

Pour le développement d’applications .NET Core sur des runners auto-hébergés, le SDK .NET est requis (pour dotnet).

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

Les runners Windows exigent que powershell.exe soit présent dans le PATH.

Si vous prévoyez de créer des bases de données CodeQL à l’aide de build-mode: none, vous devez également fournir un accès à l’internet public ou vous assurer que l’accès à un flux NuGet privé est disponible.

Détection automatique Linux et macOS

1. Appeler dotnet build sur le fichier solution (.sln) ou projet (.csproj) le plus proche de la racine.
2. Appeler MSbuild sur le fichier de solution ou de 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 ressemblant à un script de build —build et build.sh (dans cet ordre).

Exigences relatives au runner pour C# sous Linux et macOS

Pour le développement d’applications .NET Core sur des runners auto-hébergés, le SDK .NET est requis (pour dotnet).

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

Si vous prévoyez de créer des bases de données CodeQL à l’aide de build-mode: none, vous devez également fournir un accès à l’internet public ou vous assurer que l’accès à un flux NuGet privé est disponible.

Indicateurs du compilateur C# injectés par CodeQL pour les builds manuels

Le traceur CodeQL permet l’extraction de tous les langages compilés en interceptant les processus de build et en transmettant les informations aux extracteurs de langage CodeQL pertinents. Le traceur injecte certains indicateurs dans l’appel du compilateur C# afin de garantir que chaque composant est compilé et inclus dans la base de données CodeQL, ce qui peut amener votre code C# à se compiler différemment de ce que vous attendez pendant l’analyse CodeQL.

/p:MvcBuildViews=true

Lorsque cette option est définie sur true, les vues des projets ASP.NET model-view-controller (MVC) sont précompilées dans le cadre du processus de build, ce qui peut aider à détecter des erreurs et améliorer les performances. Le traceur injecte cet indicateur pour s’assurer que CodeQL détecte et met en évidence des problèmes de sécurité pouvant impliquer des flux de données traversant le code généré à partir de ces vues. Pour plus d’informations, consultez Ajouter un affichage à une application MVC dans Microsoft Learn.

/p:UseSharedCompilation=false

Définir cette option sur false désactive l’utilisation de la fonctionnalité de compilation partagée, ce qui peut entraîner des temps de build plus longs. Lorsque /p:UseSharedCompilation=false n’est pas spécifié, msbuild démarre un processus serveur de compilateur et toutes les compilations seront effectuées par ce seul processus. Cependant, le traceur CodeQL dépend de l’inspection des arguments des processus nouvellement créés.

/p:EmitCompilerGeneratedFiles=true

Définir cette option sur true émet des fichiers générés par le compilateur pendant le processus de build. Cette option entraîne la génération par le compilateur de fichiers source supplémentaires utilisés pour prendre en charge des fonctionnalités telles que l’amélioration de la prise en charge des expressions régulières, la sérialisation et la génération de vues d’applications web. Ces artefacts générés ne sont généralement pas écrits sur le disque par le compilateur, mais le fait de définir l’option sur true force l’écriture des fichiers sur le disque afin que l’extracteur puisse les traiter.

Pour certains projets hérités et les projets qui utilisent des fichiers .sqlproj, vous pouvez constater que la propriété /p:EmitCompilerGeneratedFiles=true injectée entraîne des problèmes inattendus avec msbuild. Pour plus d’informations sur le dépannage, consultez Échec inattendu du compilateur C#.

Compiler Go

CodeQL prend en charge les modes de build autobuild ou manual pour le code Go.

Résumé d’Autobuild pour Go

Type de système pris en charge	Nom du 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

Détection automatique pour Go

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

Options de l’extracteur pour Go

Par défaut, le code de test (code dans les fichiers se terminant par _test.go) n’est pas analysé. Vous pouvez remplacer ce comportement avec l’option --extractor-option extract_tests=true lors de l’utilisation du CodeQL CLI, ou en définissant la variable d’environnement CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_TESTS sur true.

De plus, les répertoires vendor sont exclus par défaut de l’analyse Go de CodeQL. Vous pouvez remplacer ce comportement en passant l’option --extractor-option extract_vendor_dirs=true lors de l’utilisation du CodeQL CLI, ou en définissant la variable d’environnement CODEQL_EXTRACTOR_GO_OPTION_EXTRACT_VENDOR_DIRS sur true.

Compiler Java et Kotlin

CodeQL prend en charge les modes de build suivants :

• Java : none, autobuild, ou manual
• Kotlin : autobuild ou manual

Lorsque vous activez la configuration par défaut pour la première fois sur un dépôt, si seul du code Java est détecté, le mode de build est défini sur none. Si du code Kotlin est détecté, ou une combinaison Java + Kotlin, le mode de build est défini sur autobuild.

Si vous ajoutez ensuite du code Kotlin à un dépôt qui utilise le mode de build none, l’analyse CodeQL affiche un message d’avertissement expliquant que Kotlin n’est pas pris en charge. Vous devrez désactiver la configuration par défaut puis la réactiver. Lorsque vous réactivez la configuration par défaut, le mode de build passera à autobuild afin que les deux langages puissent être analysés. Vous pouvez aussi passer à une configuration avancée. Pour plus d’informations, consultez « Avertissement : X fichiers Kotlin détectés dans votre projet qui n'ont pas pu être traités sans compilation ».

Analyse sans build pour Java

CodeQL tentera d’exécuter Gradle ou Maven pour extraire des informations de dépendances précises (mais sans lancer de build), puis créera une base de données à partir de tous les fichiers Java présents. Chaque fichier de projet Maven ou Gradle racine (un script de build sans script de build présent dans un répertoire ancêtre) est interrogé pour obtenir des informations de dépendances, et les versions de dépendances les plus récentes sont privilégiées en cas de conflit. Pour plus d’informations sur les exigences relatives au runner pour exécuter Maven ou Gradle, consultez Exigences relatives au runner pour Java.

Précision de l’analyse sans build pour Java

La création d’une base de données Java CodeQL sans build peut produire des résultats moins précis que l’utilisation du autobuild ou d’étapes de build manuelles si :

• Les scripts de build Gradle ou Maven ne peuvent pas être interrogés pour obtenir des informations sur les dépendances et les déductions de dépendances (basées sur les noms de packages Java) sont inexactes.
• Le dépôt génère normalement du code pendant le processus de build. Ce code aurait été analysé si vous aviez créé la base de données CodeQL à l’aide d’un mode différent.

Vous pouvez garantir une analyse plus précise en suivant les étapes suivantes :

• Fournissez un accès à l’internet public ou assurez-vous que l’accès à un dépôt d’artefacts privé est disponible.
• Vérifiez si le dépôt requiert plusieurs versions d’une même dépendance. CodeQL ne peut utiliser qu’une seule version et choisit généralement la plus récente lorsqu’il existe plusieurs versions. Cette approche peut ne pas convenir à tous les dépôts.
• Vérifiez si plus d’une version de l’API du JDK est requise par différents fichiers source Java. Lorsque plusieurs versions sont détectées, CodeQL utilisera la version la plus élevée requise par un script de build. Cela peut signifier que certains fichiers nécessitant une version inférieure du JDK seront partiellement analysés. Par exemple, si certains fichiers nécessitent JDK 8 mais qu’une exigence JDK 17 est détectée dans un ou plusieurs scripts de build, CodeQL utilisera JDK 17. Les fichiers nécessitant JDK 8 et qui ne peuvent pas être compilés avec JDK 17 seront partiellement analysés.
• Évitez les collisions de noms de classes (par exemple plusieurs fichiers définissant org.myproject.Test), sinon cela peut entraîner l’absence de cibles d’appel de méthode, ce qui a un impact sur l’analyse de flux de données.

Résumé d’Autobuild pour Java

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

Détection automatique pour Java

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 relatives au runner pour Java

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

• Si le runner est utilisé pour analyser des dépôts nécessitant une seule version de Java, la version de JDK appropriée doit être installée et présente dans la variable PATH (pour que java et javac puissent être trouvés).

• Si le runner est utilisé pour analyser des dépôts nécessitant plusieurs versions de Java, les versions de JDK appropriées doivent être installées et peuvent être spécifiées via le fichier toolchains.xml. Il s’agit d’un fichier de configuration, généralement utilisé par Apache Maven, qui permet de spécifier l’emplacement des outils, leur version et toute configuration supplémentaire requise pour les utiliser. Pour plus d’informations, consultez le 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 devraient être présents dans la variable PATH, mais ils ne seront pas indispensables dans tous les cas :

•         `mvn` (Apache Maven)
  

•           `gradle` (Gradle)
  

•         `ant` (Apache Ant)
  

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

Les runners Windows exigent que powershell.exe soit présent dans le PATH.

Compiler Swift

CodeQL prend en charge les modes de build autobuild ou manual pour le code Swift.

Résumé d’Autobuild pour Swift

Type de système pris en charge	Nom du 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.

L’analyse du code Swift utilise des exécuteurs macOS par défaut.

Code scanning du code Swift n’est pas pris en charge pour les exécuteurs qui font partie d’un ARC Actions Runner Controller, car les exécuteurs ARC utilisent uniquement Linux et Swift nécessite des exécuteurs macOS. Toutefois, vous pouvez avoir un mélange d’exécuteurs ARC et d’exécuteurs macOS auto-hébergés. Pour plus d’informations, consultez « Actions Runner Controller ».

Personnalisation de la compilation Swift dans un Workflow d’analyse CodeQL

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