Création et test de code Rust

Introduction

Ce guide explique comment générer, tester et publier un package Rust.

Les exécuteurs hébergés dans GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment les dépendances pour Rust. Pour obtenir la liste complète des logiciels à jour et des versions préinstallées de Rust, consultez « À propos des exécuteurs hébergés par GitHub ».

Prérequis

Vous devez déjà être familiarisé avec la syntaxe YAML et savoir comment elle s’utilise avec GitHub Actions. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Il est recommandé de connaître les bases du langage Rust. Pour plus d’informations, consultez Prise en main de Rust.

Utilisation d’un modèle de flux de travail Rust

Pour démarrer rapidement, ajoutez un modèle de workflow au répertoire .github/workflows de votre référentiel.

GitHub fournit un modèle de flux de travail Rust qui devrait fonctionner pour la plupart des projets Rust de base. Les sections suivantes de ce guide donnent des exemples de la manière dont vous pouvez personnaliser ce modèle de workflow.

Sur GitHub, accédez à la page principale du référentiel.
Sous le nom de votre dépôt, cliquez sur Actions.
Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur Nouveau workflow.
La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « Rust ».
Filtrez la sélection des flux de travail en cliquant sur Intégration continue.
Dans le flux de travail « Rust – par GitHub Actions », cliquez sur Configurer.
Modifiez le workflow en fonction des besoins. Par exemple, modifiez la version de Rust.
Cliquez sur Valider les changements.

Le fichier de workflow rust.yml est ajouté à l’annuaire .github/workflows de votre référentiel.

Spécification d’une version Rust

Les exécuteurs hébergés dans GitHub incluent une version récente de la chaîne d’outils Rust. Vous pouvez utiliser rustup pour signaler la version installée sur un exécuteur, remplacer la version et installer différentes chaînes d’outils. Pour plus d’informations, consultez The rustup book.

Cet exemple montre les étapes que vous pouvez utiliser pour configurer votre environnement d’exécuteur afin d’utiliser le build nocturne de Rust et de signaler la version.

YAML

      - name: Temporarily modify the rust toolchain version
        run: rustup override set nightly
      - name: Output rust version for educational purposes
        run: rustup --version

      - name: Temporarily modify the rust toolchain version
        run: rustup override set nightly
      - name: Output rust version for educational purposes
        run: rustup --version

Mise en cache des dépendances

Vous pouvez mettre en cache et restaurer des dépendances à l’aide de l’action Cache. Cet exemple part du principe que votre référentiel contient un fichier Cargo.lock.

YAML

      - name: Cache
      - uses: actions/cache@v4
        with:
          path: |
            ~/.cargo/registry
            ~/.cargo/git
            target
          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

      - name: Cache
      - uses: actions/cache@v4
        with:
          path: |
            ~/.cargo/registry
            ~/.cargo/git
            target
          key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

Si vous avez des exigences personnalisées ou avez besoin de contrôles plus fins pour la mise en cache, vous devez explorer d’autres options de configuration pour l’action cache. Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».

Génération et test de votre code

Vous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code. Cet exemple de workflow montre comment utiliser cargo build et cargo test dans un travail :

YAML

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        BUILD_TARGET: [release] # refers to a cargo profile
    outputs:
      release_built: ${{ steps.set-output.outputs.release_built }}
    steps:
      - uses: actions/checkout@v4
      - name: Build binaries in "${{ matrix.BUILD_TARGET }}" mode
        run: cargo build --profile ${{ matrix.BUILD_TARGET }}
      - name: Run tests in "${{ matrix.BUILD_TARGET }}" mode
        run: cargo test --profile ${{ matrix.BUILD_TARGET }}

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        BUILD_TARGET: [release] # refers to a cargo profile
    outputs:
      release_built: ${{ steps.set-output.outputs.release_built }}
    steps:
      - uses: actions/checkout@v4
      - name: Build binaries in "${{ matrix.BUILD_TARGET }}" mode
        run: cargo build --profile ${{ matrix.BUILD_TARGET }}
      - name: Run tests in "${{ matrix.BUILD_TARGET }}" mode
        run: cargo test --profile ${{ matrix.BUILD_TARGET }}

Le mot clé release utilisé dans cet exemple correspond à un profil de cargo. Vous pouvez utiliser n’importe quel profil que vous avez défini dans votre fichier Cargo.toml.

Publication de votre package ou bibliothèque dans crates.io

Une fois que vous avez configuré votre flux de travail pour générer et tester votre code, vous pouvez utiliser un secret pour vous connecter à crates.io et publier votre package.

YAML

      - name: Login into crates.io
        run: cargo login ${{ secrets.CRATES_IO }}
      - name: Build binaries in "release" mode
        run: cargo build -r
      - name: "Package for crates.io"
        run: cargo package # publishes a package as a tarball
      - name: "Publish to crates.io"
        run: cargo publish # publishes your crate as a library that can be added as a dependency

      - name: Login into crates.io
        run: cargo login ${{ secrets.CRATES_IO }}
      - name: Build binaries in "release" mode
        run: cargo build -r
      - name: "Package for crates.io"
        run: cargo package # publishes a package as a tarball
      - name: "Publish to crates.io"
        run: cargo publish # publishes your crate as a library that can be added as a dependency

En cas d’erreurs lors de la génération et de l’empaquetage de la crate, vérifiez les métadonnées de votre manifeste, le fichier Cargo.toml, voir Le format manifeste. Vous devez également vérifier votre fichier Cargo.lock et consulter Cargo.toml vs Cargo.lock.

Empaquetage des données de workflow en tant qu’artefacts

Une fois que le flux de travail est terminé, vous pouvez télécharger les artefacts résultants à des fins d’analyse ou d’utilisation dans un autre flux de travail. Vous pouvez ajouter ces exemples d’étapes au flux de travail pour télécharger une application à utiliser par un autre flux de travail.

YAML

      - name: Upload release artifact
        uses: actions/upload-artifact@v4
        with:
          name: <my-app>
          path: target/${{ matrix.BUILD_TARGET }}/<my-app>

      - name: Upload release artifact
        uses: actions/upload-artifact@v4
        with:
          name: <my-app>
          path: target/${{ matrix.BUILD_TARGET }}/<my-app>

Pour utiliser l’artefact téléchargé dans un autre projet, vérifiez que vos flux de travail disposent des autorisations appropriées pour le référentiel, voir Authentification par jeton automatique. Vous pouvez utiliser ces exemples d’étapes pour télécharger l’application créée dans le flux de travail précédent et la publier sur GitHub.

YAML

      - uses: actions/checkout@v4
      - name: Download release artifact
        uses: actions/download-artifact@v4
        with:
          name: <my-app>
          path: ./<my-app>
      - name: Publish built binary to GitHub releases
      - run: |
          gh release create --generate-notes ./<my-app>/<my-project>#<my-app>

      - uses: actions/checkout@v4
      - name: Download release artifact
        uses: actions/download-artifact@v4
        with:
          name: <my-app>
          path: ./<my-app>
      - name: Publish built binary to GitHub releases
      - run: |
          gh release create --generate-notes ./<my-app>/<my-project>#<my-app>

Dans cet article