> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Actions in Blueprints

> Verwenden Sie GitHub Actions, um Sprachen, Tools und SDKs in Ihrer Devin-Umgebung zu installieren, ohne Shell-Skripte schreiben zu müssen.

Anstatt Shell-Skripte zum Installieren von Tools zu schreiben, können Sie GitHub Actions direkt in den Abschnitten `initialize` oder `maintenance` Ihres Blueprints angeben. Devin lädt die Action während des Snapshot-Builds herunter und führt sie aus – genauso wie die CI-Runner von GitHub Actions Actionschritte ausführen.

Das ist besonders nützlich für Actions zum Einrichten von Sprachen wie `setup-python`, `setup-node` und `setup-go`, die Versionsverwaltung und PATH-Konfiguration automatisch übernehmen.

<div id="syntax">
  ## Syntax
</div>

Fügen Sie in einem beliebigen Abschnitt Ihres Blueprints einen `uses`-Schritt hinzu:

```yaml theme={null}
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
```

| Feld   | Typ               | Beschreibung                                                            |
| ------ | ----------------- | ----------------------------------------------------------------------- |
| `name` | string (optional) | Menschenlesbare Bezeichnung, die in Build-Logs angezeigt wird           |
| `uses` | string            | GitHub Action-Referenz (siehe [Format](#action-reference-format) unten) |
| `with` | map (optional)    | Eingabeparameter, die an die Action übergeben werden                    |
| `env`  | map (optional)    | Zusätzliche Umgebungsvariablen für den Schritt                          |

<Info>
  Ein Schritt muss entweder `run` (ein Shell-Befehl) **oder** `uses` (eine Action) angeben, nicht beides.
</Info>

<div id="action-reference-format">
  ## Format für Aktionsreferenzen
</div>

```
github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>
```

Sowohl das Präfix `github.com/` als auch das Suffix `@<ref>` sind **erforderlich**. Die Ref ist in der Regel ein Versions-Tag wie `v5`.

**Beispiele:**

| Referenz                                    | Worauf sie verweist                                              |
| ------------------------------------------- | ---------------------------------------------------------------- |
| `github.com/actions/setup-python@v5`        | `actions/setup-python` mit Tag `v5`                              |
| `github.com/actions/setup-node@v4`          | `actions/setup-node` mit Tag `v4`                                |
| `github.com/gradle/actions/setup-gradle@v4` | Repo `gradle/actions`, Unterverzeichnis `setup-gradle`, Tag `v4` |

<div id="passing-inputs">
  ## Eingaben übergeben
</div>

Verwenden Sie das Feld `with`, um Eingaben an die Action zu übergeben. Alle Werte werden als Strings behandelt, entsprechend dem Verhalten von GitHub Actions:

```yaml theme={null}
initialize:
  - uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
```

<Warning>
  Versionsnummern in `with`-Werten **immer in Anführungszeichen setzen**. YAML interpretiert `3.10` ohne Anführungszeichen als Fließkommazahl `3.1` – und das ist nicht gewollt. Schreiben Sie stattdessen `python-version: "3.10"`.
</Warning>

<div id="setting-environment-variables">
  ## Umgebungsvariablen festlegen
</div>

Verwenden Sie das Feld `env`, um Umgebungsvariablen festzulegen, die auf einen einzelnen Aktionsschritt beschränkt sind:

```yaml theme={null}
initialize:
  - uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
    env:
      RUNNER_DEBUG: "1"
```

Von einer Aktion gesetzte Umgebungsvariablen (über `GITHUB_ENV` oder `GITHUB_PATH`) werden automatisch an die nachfolgenden Schritte im Blueprint weitergegeben.

<div id="examples">
  ## Beispiele
</div>

<div id="python-project-with-a-specific-version">
  ### Python-Projekt mit einer bestimmten Python-Version
</div>

```yaml theme={null}
initialize:
  - name: Install Python 3.12
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

maintenance: |
  pip install -r requirements.txt

knowledge:
  - name: test
    contents: pytest
```

<div id="multi-language-project">
  ### Mehrsprachiges Projekt
</div>

```yaml theme={null}
initialize:
  - name: Install Node.js
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
  - name: Install Python
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
  - name: Install Go
    uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.22"
```

<div id="mixing-actions-with-shell-commands">
  ### Actions mit Shell-Befehlen kombinieren
</div>

Actions und Shell-Befehle können im selben Abschnitt beliebig kombiniert werden:

```yaml theme={null}
initialize:
  - name: Install Python
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"
  - name: Install project tools
    run: pip install ruff pytest
  - name: Install Node.js
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"
  - name: Install frontend deps
    run: npm install -g pnpm
```

<div id="java-project-with-gradle">
  ### Java-Projekt mit Gradle
</div>

```yaml theme={null}
initialize:
  - name: Install JDK 21
    uses: github.com/actions/setup-java@v4
    with:
      java-version: "21"
      distribution: "temurin"
  - name: Install Gradle
    uses: github.com/gradle/actions/setup-gradle@v4

maintenance: |
  ./gradlew dependencies

knowledge:
  - name: build
    contents: ./gradlew build
  - name: test
    contents: ./gradlew test
```

<div id="actions-vs-shell-scripts">
  ### Actions vs. Shell-Skripte
</div>

Sie müssen keine Actions verwenden — normale Shell-Befehle funktionieren genauso gut. Actions sind praktisch, wenn das entsprechende Shell-Skript lang oder fehleranfällig wäre.

<Tabs>
  <Tab title="Mit GitHub Actions">
    ```yaml theme={null}
    initialize:
      - uses: github.com/actions/setup-go@v5
        with:
          go-version: "1.23"
    ```
  </Tab>

  <Tab title="Entsprechendes Shell-Skript">
    ```yaml theme={null}
    initialize: |
      GO_VERSION=1.23.5
      ARCH=$(dpkg --print-architecture)
      curl -fsSL "https://go.dev/dl/go${GO_VERSION}.linux-${ARCH}.tar.gz" \
        | sudo tar -xz -C /usr/local
      echo 'export PATH="/usr/local/go/bin:$HOME/go/bin:$PATH"' \
        | sudo tee /etc/profile.d/golang.sh > /dev/null
    ```
  </Tab>
</Tabs>

<div id="how-it-works">
  ## Wie es funktioniert
</div>

Wenn Devin während eines Snapshot-Builds auf einen `uses`-Schritt stößt:

1. **Lädt** das Action-Repo herunter (flacher Klon der angepinnten Ref)
2. **Liest** die `action.yml`-Metadaten der Action, um Laufzeit und Einstiegspunkte zu bestimmen
3. **Erstellt** die Ausführungsumgebung mit den Variablen `INPUT_*`, `GITHUB_*` und `RUNNER_*`
4. **Führt** den `pre`-Schritt der Action aus (falls definiert) und anschließend den `main`-Einstiegspunkt
5. **Überträgt** Nebeneffekte — alle Einträge, die die Action in `GITHUB_PATH` oder `GITHUB_ENV` schreibt, werden auf nachfolgende Blueprint-Schritte angewendet

<Info>
  Actions werden außerhalb eines echten GitHub-Workflows ausgeführt. Kontextvariablen wie `github.repository` werden mit Platzhalterwerten befüllt. Actions, die Live-Zugriff auf die GitHub-API erfordern (z. B. Kommentare zu Pull Requests oder das Erstellen von Releases), funktionieren in Blueprints nicht.
</Info>

<div id="limitations">
  ## Einschränkungen
</div>

* **Nur Node.js-Actions** — Unterstützt werden nur GitHub Actions, die eine Node.js-Laufzeit (`node16`, `node20`, `node24`) verwenden. Docker-basierte und komposite Actions werden nicht unterstützt.
* **Kein `post`-Lebenszyklus** — Devin führt die Schritte `pre` und `main` aus, überspringt aber `post`-Bereinigungsschritte, da Builds in kurzlebigen VMs ausgeführt werden.
* **GitHub-Kontext als Platzhalter** — Actions, die auf GitHub-API-Aufrufe, Workflow-Ereignisdaten oder Repository-Kontext angewiesen sind, funktionieren möglicherweise nicht korrekt, da diese Werte in der Build-Umgebung nur Platzhalter sind.
* **Versionen anpinnen** — Verwenden Sie für reproduzierbare Builds immer ein bestimmtes Versions-Tag (z. B. `@v5`) statt eines Branchnamens.

<div id="related-pages">
  ## Verwandte Seiten
</div>

* [Deklarative Umgebungskonfiguration](/de/onboard-devin/environment/blueprints)
* [Blueprint-Referenz](/de/onboard-devin/environment/blueprint-reference)
* [Vorlagenbibliothek](/de/onboard-devin/environment/templates)