Skip to main content

Erstellen und Testen eines Rust-Projekts

Du kannst einen Continuous-Integration-Workflow (CI) erstellen, um dein Rust-Projekt zu kompilieren und zu testen.

Einführung

In dieser Anleitung erfährst du, wie du ein Rust-Paket erstellst, testest und veröffentlichst.

GitHub-gehostete Runner haben einen Toolcache mit vorinstallierter Software, die Abhängigkeiten für Rust einschließt. Eine vollständige Liste der aktuellen Software und der vorinstallierten Versionen von Rust findest du unter Informationen zu von GitHub gehostete Runnern.

Voraussetzungen

Du solltest bereits mit der YAML-Syntax vertraut sein und wissen, wie sie mit GitHub Actions verwendet wird. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Du solltest über grundlegende Kenntnisse in Bezug auf die Rust-Programmiersprache verfügen. Weitere Informationen findest du unter Erste Schritte mit Rust.

Verwenden einer Rust-Workflowvorlage

Fügen Sie für einen schnellen Einstieg dem Verzeichnis .github/workflows Ihres Repositorys eine Workflowvorlage hinzu.

GitHub bietet eine Rust-Workflowvorlage, die für die meisten grundlegenden Rust-Projekte funktionieren sollte. In den nachfolgenden Abschnitten dieser Anleitung finden Sie Beispiele dafür, wie diese Workflowvorlage angepasst werden kann.

  1. Navigieren Sie auf GitHub zur Hauptseite des Repositorys.

  2. Klicke unter dem Namen deines Repositorys auf Aktionen.

    Screenshot: Registerkarten für das Repository „github/docs“. Die Registerkarte „Aktionen“ ist mit einem orangefarbenen Rahmen hervorgehoben.

  3. Wenn du bereits über einen Workflow im Repository verfügst, klicke auf Neuer Workflow.

  4. Auf der Seite „Workflow auswählen“ wird eine Auswahl empfohlener Workflowvorlagen angezeigt. Suche nach „Rust“.

  5. Filtern Sie die Auswahl von Workflows, indem Sie auf Continuous Integration klicken.

  6. Klicke im Workflow „Rust – von GitHub Actions“ auf Configure.

    Screenshot: Seite „Einen Workflow auswählen“ Die Schaltfläche „Configure“ auf dem Workflow „Rust“ ist mit einem orangefarbenen Umriss hervorgehoben.

  7. Bearbeiten Sie den Workflow nach Bedarf. Beispiel: Ändere die Rust-Version.

  8. Klicke auf Änderungen committen.

Angeben einer Rust-Version

GitHub-gehostete Runner schließen eine aktuelle Version der Rust-Toolkette ein. Du kannst rustup verwenden, um die auf einem Runner installierte Version zu melden, die Version zu überschreiben und verschiedene Toolketten zu installieren. Weitere Informationen findest du unter The rustup book.

Dieses Beispiel veranschaulicht die Schritte, mit deren Hilfe du deine Runnerumgebung so einrichten kannst, dass du den nightly-Build von Rust verwenden und die Version melden kannst.

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

Abhängigkeiten „cachen“ (zwischenspeichern)

Du kannst Abhängigkeiten mithilfe der Aktion „Cache“ zwischenspeichern und wiederherstellen. In diesem Beispiel wird davon ausgegangen, dass dein Repository eine Cargo.lock-Datei enthält.

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

Wenn du über benutzerdefinierte Anforderungen verfügst oder präzisere Steuerelemente für das Zwischenspeichern benötigst, solltest du weitere Konfigurationsoptionen für die Aktion cache erkunden. Weitere Informationen finden Sie unter Abhängigkeiten zwischenspeichern um Workflows zu beschleunigen.

Deinen Code bauen und testen

Du kannst die gleichen Befehle verwenden, die du auch lokal verwendest, um deinen Code zu bauen und zu testen. In diesem Beispielworkflow wird veranschaulicht, wie die Befehle cargo build und cargo test in einem Auftrag verwendet werden:

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 }}

Das in diesem Beispiel verwendete Schlüsselwort release entspricht einem Cargo-Profil. Du kannst jedes beliebige Profil verwenden, das du in deiner Cargo.toml-Datei definiert hast.

Veröffentlichen deines Pakets oder deiner Bibliothek auf crates.io

Nachdem du deinen Workflow zum Erstellen und Testen deines Codes eingerichtet hast, kannst du dich mit einem Geheimnis bei crates.io anmelden und dein Paket veröffentlichen.

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

Wenn Fehler beim Erstellen und Verpacken der Crate auftreten, überprüfe die Metadaten in deiner Manifestdatei Cargo.toml. Weitere Informationen findest du unter Manifestformat. Du solltest außerdem deine Cargo.lock-Datei überprüfen. Weitere Informationen findest du unter Cargo.toml gegen Cargo.lock.

Workflow-Daten als Artefakte paketieren

Nach Abschluss eines Workflows kannst du die resultierenden Artefakte zur Analyse hochladen oder in einem anderen Workflow verwenden. Du kannst dem Workflow diese Beispielschritte hinzufügen, um eine Anwendung für die Verwendung durch einen anderen Workflow hochzuladen.

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

Stelle zur Verwendung des hochgeladenen Artefakts in einem anderen Auftrag sicher, dass deine Workflows über die richtigen Berechtigungen für das Repository verfügen. Weitere Informationen findest du unter Automatische Tokenauthentifizierung. Du kannst diese Beispielschritte verwenden, um die im vorherigen Workflow erstellte App herunterzuladen und auf GitHub zu veröffentlichen.

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>