Skip to main content
Instead of writing shell scripts to install tools, you can reference GitHub Actions directly in your blueprint’s initialize section. Devin downloads and runs the action during the snapshot build, the same way GitHub’s CI runners execute action steps. This is especially useful for language setup actions like setup-python, setup-node, and setup-go, which handle version management and PATH configuration automatically.

​
Syntax

Add a uses step to the initialize section of your blueprint:
A step must specify either run (a shell command) or uses (an action), not both.
uses steps are not supported in maintenance. A maintenance step with uses fails the snapshot build with 'uses' steps are not supported in maintenance sections ... Actions can only run during initialize. Put actions in initialize and keep maintenance to run steps. Organization- and enterprise-level post-build steps can also use actions.

​
Action reference format

The github.com/ prefix and @<ref> suffix are both required. The ref is typically a version tag like v5. Examples:

​
Passing inputs

Use the with field to pass inputs to the action. All values are treated as strings, matching GitHub Actions behavior:
Always quote version numbers in with values. YAML interprets bare 3.10 as the float 3.1, which is not what you want. Write python-version: "3.10" instead.

​
Setting environment variables

Use the env field to set environment variables scoped to a single action step:
Environment variables set by an action (via GITHUB_ENV or GITHUB_PATH) are automatically propagated to subsequent steps in the blueprint.

​
Examples

​
Python project with a specific version

​
Multi-language project

​
Mixing actions with shell commands

Actions and shell commands can be freely mixed in the same section:

​
Java project with Gradle

​
Actions vs. shell scripts

You don’t have to use actions — plain shell commands work fine. Actions are a convenience when the equivalent shell script would be long or error-prone.

​
How it works

When Devin encounters a uses step during a snapshot build:
  1. Downloads the action repository (shallow clone at the pinned ref)
  2. Reads the action’s action.yml metadata to determine the action type (runs.using) and entry points
  3. Builds the execution environment with INPUT_*, GITHUB_*, and RUNNER_* variables
  4. Runs the action based on its type:
    • Node.js actions — runs the pre script (if defined), then main
    • Composite actions — runs each step in runs.steps in order, including nested run and uses steps
    • Docker actions — builds the image from the action’s Dockerfile (or pulls a docker:// image), then runs the container, including pre-entrypoint if defined
  5. Propagates side effects — any entries written to GITHUB_PATH or GITHUB_ENV by the action are applied to subsequent blueprint steps
Actions run outside of a real GitHub workflow. Context variables like github.repository are populated with stub values. Actions that require live GitHub API access (e.g., commenting on PRs, creating releases) will not work in blueprints.

​
Limitations

  • Supported action types — Blueprints support these action types (runs.using):
  • Not in maintenance — uses steps run in initialize and post-build, but can’t run in maintenance. See Syntax.
  • No post lifecycle — Devin runs pre and main steps (and a Docker action’s pre-entrypoint) but skips post cleanup steps (post and post-entrypoint), since builds run in disposable VMs.
  • Stub GitHub context — Actions that rely on GitHub API calls, workflow event data, or repository context may not work correctly because these values are placeholders in the build environment.
  • Pin your versions — Always reference a specific version tag (e.g., @v5) rather than a branch name for reproducible builds.