Deploy to Astro

This GitHub action automates deploying code from your GitHub repository to a Deployment on Astro, Astronomer's data orchestration platform and managed service for Apache Airflow.

You can use and configure this GitHub action to easily deploy Apache Airflow DAGs to an Airflow environment on Astro. Specifically, you can:

Avoid manually running astro deploy with the Astro CLI every time you make a change to your Astro project.
Automate deploying code to Astro when you merge changes to a certain branch in your repository.
Incorporate unit tests for your DAGs as part of the deploy process.
Create/delete a Deployment Preview. A Deployment Preview is an Astro Deployment that mirrors the configuration of your original Deployment.

This GitHub action runs as a step within a GitHub workflow file. When your CI/CD pipeline is triggered, this action:

Checks out your GitHub repository.
Optionally creates or deletes a Deployment Preview to test your code changes on before deploying to production.
Checks whether your commit only changed DAG code.
Optional. Tests DAG code with pytest. See Run tests with pytest.
Either runs:
- astro deploy --dags if the commit only includes DAG code changes,
- or astro deploy (as well as astro dev parse) if the commit includes any non-DAG-code-related changes.

Prerequisites

To use this GitHub action, you need:

An Astro project. See Create a project.
A Deployment on Astro. See Create a Deployment.
An Organization, Workspace, or Deployment API Token. See API Tokens
Or (deprecated) a Deployment API key ID and secret. See Deployment API keys.
The setup-astro-cli action (recommended) to install and manage the Astro CLI in your workflow. See Installing the Astro CLI.

Tip

Astronomer recommends using GitHub Actions secrets to store ASTRO_API_TOKEN or Deployment API Keys. See the example in Workflow file examples.

Use this action

To use this action, read Automate code deploys with CI/CD. You will:

Create a GitHub Actions workflow in your repository that uses the latest version of this action. For example, astronomer/deploy-action@v0.17.0.
Configure the workflow to fit your team's use case. This could include creating a deployment preview or adding tests. See Configuration options.
Make changes to your Astro project files in GitHub and let this GitHub Actions workflow take care of deploying your code to Astro.

Tip

Astronomer recommends setting up multiple environments on Astro. See the Multiple branch GitHub Actions workflow in Astronomer documentation.

Configuration options

The following table lists the configuration options for the Deploy to Astro action.

Name	Default	Description
`action`	`deploy`	Specify what action you would like to take. Use this option to create or delete deployment previews. Specify either `deploy`, `create-deployment-preview`, `delete-deployment-preview` or `deploy-deployment-preview`. If using `deploy` or `deploy-deployment-preview` one should also specify `deploy-type`.
`deploy-type`	`infer`	Specify the type of deploy you would like to do. Use this option to deploy images and/or DAGs, a DBT project, or a non-DAG bundle. Possible options are `infer`, `dags-only`, `image-and-dags`, `image-only`, `dbt` or `non-dags`. `infer` option would infer between DAG only deploy and image and DAG deploy based on updated files. For description on each deploy type checkout deploy type details
`image-trigger-paths`	``	Comma- or newline-separated list of paths outside `root-folder` that should also trigger a deploy when changed. Useful in monorepos where files built or copied into the image at deploy time (e.g. generated protos) live outside the Astro project. A change under any of these paths forces an image deploy instead of being skipped. Paths are matched as prefixes against repo-root-relative file paths, so include a trailing slash to scope to a directory (e.g. `proto/`). Only applies to the `infer`, `image-and-dags`, and `image-only` deploy types. For `dbt` and `non-dags` deploys, use `bundle-trigger-paths`.
`bundle-trigger-paths`	``	Comma- or newline-separated list of paths outside `root-folder` that should also trigger a bundle deploy when changed. Useful in monorepos where a bundle depends on shared files that live outside its own directory. Paths are matched as prefixes against repo-root-relative file paths, so include a trailing slash to scope to a directory (e.g. `shared/macros/`). Only applies to the `dbt` and `non-dags` deploy types.
`skip-unchanged`	`true`	When `true` (default), the action skips the deploy if no changed files fall under `root-folder` or `dags-path` (or `image-trigger-paths` / `bundle-trigger-paths`). Set to `false` to disable this diff-based skip and always run the deploy dictated by `deploy-type`. This is the closest replacement for the deprecated `deploy-image: true` behavior.
`deployment-id`	`false`	Specifies the id of the deployment you to make a preview from or are deploying too.
`deployment-name`	`false`	Specifies The name of the deployment you want to make preview from or are deploying too. Cannot be used with `deployment-id`
`description`		Configure a description for a deploy to Astro. Description will be visible in the Deploy History tab.
`root-folder`	`.`	Path to the Astro project, or to the bundle directory for `dbt` and `non-dags` deploys. Required with `deploy-type: non-dags`.
`parse`	`false`	When set to `true`, DAGs are parsed for errors before deploying to Astro. Note that when an image deploy is performed (i.e. `astro deploy`), parsing is also executed by default. Parsing is not performed automatically for DAG-only deploys (i.e. `astro deploy --dags`).
`pytest`	`false`	When set to `true`, all pytests in the `tests` directory of your Astro project are run before deploying to Astro. See Run tests with pytest
`pytest-file`	(all tests run)	Specifies a custom pytest file to run with the pytest command. For example, you could specify `/tests/test-tags.py`.
`force`	`false`	When set to `true`, your code is deployed and skips any pytest or parsing errors.
`image-name`		Specifies a custom, locally built image to deploy. To be used with `deploy-type` set to `image-and-dags`, `infer`, or `image-only`, and not with `parse`, `pytest`, or `build-secrets`, since the image is deployed as it was built.
`workspace`		Workspace id to select. Only required when `ASTRO_API_TOKEN` is given an organization token.
`preview-name`	`false`	Specifies custom preview name. By default this is branch name “_” deployment name.
`checkout`	`true`	Whether to checkout the repo as the first step. Set this to false if you want to modify repo contents before invoking the action. Your custom checkout step needs to have `fetch-depth` of `0` and `ref` equal to `${{ github.event.after }}` so all the commits in the PR are checked out. Look at the checkout step that runs within this action for reference.
`deploy-image`	`false`	If true image and DAGs will deploy for any action that deploys code. NOTE: This option is deprecated and will be removed in a future release. Use `deploy-type: image-and-dags` instead.
`build-secrets`	``	Newline-delimited list of Docker build secrets, one `docker build --secret` specification per line (e.g. `id=mysecret,src=secrets.txt`). Each line is passed to `astro deploy` as its own `--build-secret` flag. See https://docs.docker.com/build/building/secrets/ for more information.
`mount-path`	``	Path to mount the bundle in Airflow, for reference by DAGs. Required with `deploy-type: non-dags`. With `deploy-type: dbt` it is optional and defaults to /usr/local/airflow/dbt/{dbt project name}
`non-dags-bundle-type`	``	Free-form label identifying the kind of non-DAG bundle being deployed (e.g. `dbt`), shown in the Deploy History tab. Only applies to the `non-dags` deploy type. Requires Astro CLI 1.44.0 or higher.
`dag-bundle-name`	``	Deploy DAGs to a named DAG bundle on the Deployment instead of the default bundle. Requires Airflow 3, and the bundle must already exist on the Deployment; `create-deployment-preview` copies the original Deployment's bundles to the preview. Use with `deploy-type: dags-only` or `image-and-dags`. Requires Astro CLI 1.44.0 or higher.
`dags-path`	``	Deploy DAGs from this path, relative to `root-folder`, instead of the project's `dags` directory. Useful for serving several DAG bundles out of one repository, one action invocation per bundle. A `dags-only` deploy classifies changes against this path instead of `dags/`, and with Astro CLI 1.45.0 or higher (and `parse` and `pytest` off) it needs no Astro project, so `root-folder` can be left empty. Use with `deploy-type: dags-only` or `image-and-dags`.
`no-dags-base-dir`	`false`	If true, exclude the DAGs directory prefix from the uploaded bundle. Use for Airflow 3 Deployments, where the bundle root is already on `sys.path`. Use with `deploy-type` `infer`, `dags-only`, or `image-and-dags`, and not with `image-name`.
`checkout-submodules`	`false`	Whether to checkout submodules when cloning the repository: `false` to disable (default), `true` to checkout submodules or `recursive` to recursively checkout submodules. Works only when `checkout` is set to `true`. Works only when `checkout` is set to `true`.
`sparse-checkout`	``	Comma- or newline-separated list of cone-mode sparse-checkout patterns passed to `actions/checkout`. When set, only the listed paths (plus repo-root files) are checked out, which can dramatically reduce checkout size for large monorepos. Typically set to the same value as `root-folder`. Works only when `checkout` is set to `true`. Leave empty for a full checkout (default).
`wake-on-deploy`	`false`	If true, the deployment will be woken up from hibernation before deploying. NOTE: This option overrides the deployment's hibernation override spec.
`cli-version`	`1.46.1`	The desired Astro CLI version to use. The default is pinned, so a given ref of this action always installs the same CLI version. Bump it to move. Ignored when the Astro CLI is already installed.
`wait-time`	``	The max time to wait for the deployment or deploy operation to finish successfully. If not specified, the default value would be 10 minutes. Expected value format - 300s or 5m

Outputs

The following table lists the outputs for the Deploy to Astro action.

Name	Description
`preview-id`	The ID of the created deployment preview. Only works when action=create-deployment-preview.

Deploy Type Details

The following section describe each of the deploy type input value in detail to avoid any confusion:

infer: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
if there are changes only in dags/ folder, then it will do a dags deploy
otherwise it would do a complete image deploy

image-and-dags: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
otherwise it would do a complete image deploy

dags-only: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
if all the file changes are in folders except dags folder (or dags-path, when set) then it skips deploy
if the changed files cannot be determined (a manual workflow dispatch, a new branch, or a missing diff base) it would do a dag only deploy
otherwise it would do a dag only deploy

image-only: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
otherwise it would deploy only the image, leaving existing DAGs on the deployment untouched

dbt: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
otherwise it would do a dbt deploy

non-dags: In this mode, deploy-action would run through all the file changes:

if there are no file changes in the configured root-folder then it skips deploy
otherwise it would deploy the root-folder directory as a non-DAG bundle, mounted at mount-path

Deploying on changes outside `root-folder`

By default the deploy is skipped when no changed files fall under root-folder. In monorepos, some files that end up in the image are built or copied in at deploy time and live outside the Astro project (e.g. generated protos), so a change to them would otherwise be skipped. Three inputs cover this:

image-trigger-paths: list the extra paths that feed the image. A change under any of them forces an image deploy while still skipping genuinely unrelated pushes. Applies to infer, image-and-dags, and image-only.
```
with:
  root-folder: airflow
  deploy-type: image-and-dags
  image-trigger-paths: |
    proto/
    shared/schemas/
```
bundle-trigger-paths: the same idea for bundle deploys. A change under any of them triggers a bundle deploy even when nothing under root-folder changed. Applies to dbt and non-dags.
```
with:
  root-folder: dbt
  deploy-type: dbt
  bundle-trigger-paths: |
    shared/macros/
```
skip-unchanged: false: disables the diff-based skip entirely, so the deploy dictated by deploy-type runs on every invocation. This is the closest replacement for the deprecated deploy-image: true.
```
with:
  root-folder: airflow
  deploy-type: image-and-dags
  skip-unchanged: false
```

Non-DAG bundle deploys

A non-DAG bundle is any directory deployed to a Deployment and mounted at a path, for DAGs to reference at runtime — a dbt project, a set of SQL files, a config tree. deploy-type: dbt is the older, dbt-specific form of this; deploy-type: non-dags deploys any directory and requires Astro CLI 1.44.0 or higher.

- name: Deploy SQL assets to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment-id>
    deploy-type: non-dags
    root-folder: sql
    mount-path: /usr/local/airflow/sql
    non-dags-bundle-type: sql

root-folder is the directory to deploy, and is required. mount-path is also required, and is the path DAGs use to reach the bundle's contents inside Airflow. non-dags-bundle-type is a free-form label shown in the Deploy History tab; it does not change how the bundle is handled.

Important

The bundle directory must not sit inside an Astro project. astro-project/ and sql/ as siblings works; astro-project/sql/ is rejected by the Astro CLI. Keep the bundle a sibling of the Astro project in the repository.

Named DAG bundles

On Airflow 3 Deployments, DAGs can be served from several named bundles instead of a single default one. dag-bundle-name targets one of them; the bundle must already exist on the Deployment, since the deploy does not create it. Requires Astro CLI 1.44.0 or higher.

- name: Deploy team A's DAGs
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment-id>
    deploy-type: dags-only
    dags-path: bundles/team-a
    dag-bundle-name: team-a

A named bundle's DAGs don't have to live in an Astro project. With Astro CLI 1.45.0 or higher, a dags-only deploy with dags-path set (and parse and pytest off) needs no project, so leave root-folder empty and point dags-path at the bundle's directory from the repository root. dags-path is otherwise resolved from root-folder.

To serve several DAG bundles out of one repository, use one action invocation per bundle, each with its own dags-path and dag-bundle-name. With dags-path set, a dags-only deploy classifies changes against that path instead of dags/, so each bundle only deploys when its own DAGs change. dag-bundle-name and dags-path cannot be used with deploy-type: infer (the default), which would build and deploy the project's image for any change outside the bundle: use dags-only, or image-and-dags to deliberately deploy the image as well.

no-dags-base-dir excludes the DAGs directory prefix from the uploaded bundle, which is what Airflow 3 expects when the bundle root is already on sys.path.

dag-bundle-name, dags-path, and no-dags-base-dir cannot be combined with image-name on deploys that use it, because a pre-built image carries its own DAGs. None of them can be used with deploy-type image-only, dbt, or non-dags, which deploy no DAGs.

When create-deployment-preview creates a preview, it copies the original Deployment's bundles to it: DAG bundles by name, and non-DAG bundles with their mount path, type, and the DAG bundles they are served alongside. Only the bundles are copied, not their contents, so add each bundle's deploy step (with action: deploy-deployment-preview) to the workflow that creates the preview, after the create step. See Deployment Preview Templates.

Installing the Astro CLI

Astronomer recommends using the setup-astro-cli action to install and manage the Astro CLI in your workflows. This keeps CLI installation decoupled from deployment logic, lets you pin or update CLI versions independently (including via Dependabot), and allows a single installation to be reused across multiple deploy steps.

Add setup-astro-cli as a step before any deploy-action step in your workflow:

Tip

As a security best practice, Astronomer recommends pinning all third-party actions to a full commit SHA instead of a tag in production workflows. See GitHub's security hardening guide.

steps:
- name: Install Astro CLI
  uses: astronomer/setup-astro-cli@v0.0.1

- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment-id>

Pin to a specific CLI version

steps:
- name: Install Astro CLI
  uses: astronomer/setup-astro-cli@v0.0.1
  with:
    version: "1.29.0"

- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment-id>

Use an internal mirror or air-gapped runner

steps:
- name: Install Astro CLI
  uses: astronomer/setup-astro-cli@v0.0.1
  with:
    download-url: https://mirror.example.com/astro-cli/v1.29.0/astro_linux_amd64.tar.gz

- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment-id>

Install once, deploy to multiple environments

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Install Astro CLI
      uses: astronomer/setup-astro-cli@v0.0.1

    - name: Deploy to Development
      uses: astronomer/deploy-action@v0.17.0
      with:
        deployment-id: <dev-deployment-id>

    - name: Deploy to Staging
      uses: astronomer/deploy-action@v0.17.0
      with:
        deployment-id: <staging-deployment-id>

Workflow file examples

Tip

As a security best practice, Astronomer recommends pinning all third-party actions to a full commit SHA instead of a tag in production workflows. See GitHub's security hardening guide.

In the following example, the GitHub action deploys code to Astro. This example assumes that you have one Astro Deployment and one branch. When a change is merged to the main branch, your Astro project is deployed to Astro. DAG files are parsed on every deploy and no pytests are ran.

name: Astronomer CI - Deploy code

on:
  push:
    branches:
      - main

env:
  ## Set API Token as an environment variable
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Install Astro CLI
      uses: astronomer/setup-astro-cli@v0.0.1
    - name: Deploy to Astro
      uses: astronomer/deploy-action@v0.17.0
      with:
        deployment-id: <deployment id>
        parse: true

Use the following topics to further configure the action based on your needs.

Change the Root folder

In the following example, the folder /example-dags/ is specified as the root folder.

steps:
- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    root-folder: /example-dags/

Run Pytests

In the following example, the pytest located at /tests/test-tags.py runs before deploying to Astro.

steps:
- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    pytest: true
    pytest-file: /tests/test-tags.py

Ignore parsing and testing

In the following example, force is enabled and both the DAG parse and pytest processes are skipped.

steps:
- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    force: true

Use Docker build secrets

In the following example, two Docker build secrets are exposed to the image build: one sourced from a file on the runner and one from an environment variable. The build-secrets input takes one secret specification per line.

steps:
- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  env:
    PLATFORM_PASSWORD: ${{ secrets.PLATFORM_PASSWORD }}
  with:
    deployment-id: <deployment id>
    build-secrets: |
      id=aws,src=/home/runner/.aws/credentials
      id=PLATFORM_PASSWORD,env=PLATFORM_PASSWORD

Your Astro project's Dockerfile can then mount the secrets during the build without baking them into the image:

RUN --mount=type=secret,id=aws \
    --mount=type=secret,id=PLATFORM_PASSWORD,env=PLATFORM_PASSWORD \
    AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \
    ./install-private-dependencies.sh

Deploy a custom Docker image

In the following example, a custom Docker image is built and deployed to an Astro Deployment.

name: Astronomer CI - Additional build-time args

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ## Set API Token as an environment variable
      ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}
    steps:
    - name: Check out the repo
      uses: actions/checkout@v6
    - name: Create image tag
      id: image_tag
      run: echo ::set-output name=image_tag::astro-$(date +%Y%m%d%H%M%S)
    - name: Build image
      uses: docker/build-push-action@v6
      with:
        tags: ${{ steps.image_tag.outputs.image_tag }}
        load: true
        # Define your custom image's build arguments, contexts, and connections here using
        # the available GitHub Action settings:
        # https://github.com/docker/build-push-action#customizing .
        # This example uses `build-args` , but your use case might require configuring
        # different values.
        build-args: |
          <your-build-arguments>
    - name: Deploy to Astro
      uses: astronomer/deploy-action@v0.17.0
      with:
        deployment-id: <deployment id>
        deploy-type: image-and-dags
        image-name: ${{ steps.image_tag.outputs.image_tag }}

Deploy a DBT project

In the following example we would be deploying the dbt project located at dbt folder in the Github repo

steps:
- name: DBT Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: dbt
    root-folder: dbt

Deploy DAGs and DBT project from same repo

In the following example we would setup a workflow to deploy dags/images located at astro-project and dbt deploy from dbt project located at dbt folder in the same Github repo. The CLI is installed once and reused across both deploy steps.

steps:
- name: Install Astro CLI
  uses: astronomer/setup-astro-cli@v0.0.1
  with:
    version: "1.30.0"  # DBT deploys require CLI >= 1.28.1
- name: DBT Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: dbt
    root-folder: dbt
- name: DAGs/Image Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    root-folder: astro-project/
    parse: true

Deploy several bundles from the same repo

In the following example we would deploy the image from astro-project, two named DAG bundles from bundles/, and a non-DAG bundle of SQL assets, all from the same repository. The bundles sit outside the Astro project, so each step only deploys when its own files change: a change to team A's DAGs does not redeploy team B's, or rebuild the image. See named DAG bundles and non-DAG bundle deploys for the details.

steps:
- name: Install Astro CLI
  uses: astronomer/setup-astro-cli@v0.0.1
  with:
    version: "1.45.0"  # DAG bundles deployed outside an Astro project require CLI >= 1.45.0
- name: Image Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: image-only
    root-folder: astro-project
- name: Deploy team A's DAGs
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: dags-only
    dags-path: bundles/team-a
    dag-bundle-name: team-a
- name: Deploy team B's DAGs
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: dags-only
    dags-path: bundles/team-b
    dag-bundle-name: team-b
- name: Deploy SQL assets
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    deploy-type: non-dags
    root-folder: sql
    mount-path: /usr/local/airflow/sql
    non-dags-bundle-type: sql

Wake on deploy

In the following example, the deployment is woken up from hibernation before deploying via the wake-on-deploy option.

steps:
- name: Deploy to Astro
  uses: astronomer/deploy-action@v0.17.0
  with:
    deployment-id: <deployment id>
    wake-on-deploy: true

This is especially useful when you have a deployment that is hibernated and you want to deploy to it. This option overrides the deployment's hibernation override spec.

Deployment Preview Templates

This section contains four workflow files that you will need in your repository to have a full Deployment Preview Cycle running for your Deployment. A Deployment Preview is an Astro Deployment that mirrors the configuration of your original Deployment. This Deployment Preview can be used to test your new pipelines changes before pushing them to your original Deployment. The scripts below will take your pipeline changes through the following flow:

When a new branch is created a Deployment Preview will be created based off your original Deployment
When a PR is created from a branch code changes will be deployed to the Deployment Preview
When a PR is merged into your "main" branch code changes will be deployed to the original Deployment
When a branch is deleted the corresponding Deployment Preview will also be deleted

The Deployment Preview gets copies of the original Deployment's DAG and non-DAG bundles, but not their contents. If you deploy bundles (dbt, non-dags, or dag-bundle-name), add each bundle's deploy step, with action: deploy-deployment-preview, to the workflow that creates the preview, after the create step, so a new preview starts with every bundle deployed.

Create Deployment Preview

name: Astronomer CI - Create deployment preview

on:
  create:
    branches:
    - "**"

env:
  ## Sets Deployment API key credentials as environment variables
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Create Deployment Preview
      uses: astronomer/deploy-action@v0.17.0
      with:
        action: create-deployment-preview
        deployment-id: <original deployment id>
        wait-time: 10m

Deploy to Deployment Preview

name: Astronomer CI - Deploy code to Preview

on:
  pull_request:
    branches:
      - main

env:
  ## Sets Deployment API key credentials as environment variables
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Deploy to Deployment Preview
      uses: astronomer/deploy-action@v0.17.0
      with:
        action: deploy-deployment-preview
        deployment-id: <original deployment id>

DBT Deploy to Deployment Preview

name: Astronomer - DBT Deploy code to Preview

on:
  pull_request:
    branches:
      - main

env:
  ## Sets Deployment API key credentials as environment variables
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Deploy to Deployment Preview
      uses: astronomer/deploy-action@v0.17.0
      with:
        action: deploy-deployment-preview
        deploy-type: dbt
        deployment-id: <original deployment id>
        root-folder: dbt

Delete Deployment Preview

name: Astronomer CI - Delete Deployment Preview

on:
  delete:
    branches:
    - "**"

env:
  ## Sets Deployment API key credentials as environment variables
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Delete Deployment Preview
      uses: astronomer/deploy-action@v0.17.0
      with:
        action: delete-deployment-preview
        deployment-id: <original deployment id>

Deploy to Original Deployment

name: Astronomer CI - Deploy code to Astro

on:
  push:
    branches:
      - main

env:
  ## Sets Deployment API key credentials as environment variables
  ASTRO_API_TOKEN: ${{ secrets.ASTRO_API_TOKEN }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Deploy to Astro
      uses: astronomer/deploy-action@v0.17.0
      with:
        deployment-id: <original deployment id>

Name		Name	Last commit message	Last commit date
.github/workflows		.github/workflows
e2e-setup		e2e-setup
.gitignore		.gitignore
.yamllint		.yamllint
CODEOWNERS		CODEOWNERS
LICENSE		LICENSE
README.md		README.md
action.yaml		action.yaml

Navigation Menu

Repository navigation

About

Repository files navigation

Deploy to Astro

Prerequisites

Use this action

Configuration options

Outputs

Deploy Type Details

Deploying on changes outside `root-folder`

Non-DAG bundle deploys

Named DAG bundles

Installing the Astro CLI

Pin to a specific CLI version

Use an internal mirror or air-gapped runner

Install once, deploy to multiple environments

Workflow file examples

Change the Root folder

Run Pytests

Ignore parsing and testing

Use Docker build secrets

Deploy a custom Docker image

Deploy a DBT project

Deploy DAGs and DBT project from same repo

Deploy several bundles from the same repo

Wake on deploy

Deployment Preview Templates

Create Deployment Preview

Deploy to Deployment Preview

DBT Deploy to Deployment Preview

Delete Deployment Preview

Deploy to Original Deployment

About

Releases

Packages

Used by

Contributors

Languages

Latest commit

History

Folders and files

Repository files navigation

Deploy to Astro

Prerequisites

Use this action

Configuration options

Outputs

Deploy Type Details

Deploying on changes outside root-folder

Non-DAG bundle deploys

Named DAG bundles

Installing the Astro CLI

Pin to a specific CLI version

Use an internal mirror or air-gapped runner

Install once, deploy to multiple environments

Workflow file examples

Change the Root folder

Run Pytests

Ignore parsing and testing

Use Docker build secrets

Deploy a custom Docker image

Deploy a DBT project

Deploy DAGs and DBT project from same repo

Deploy several bundles from the same repo

Wake on deploy

Deployment Preview Templates

Create Deployment Preview

Deploy to Deployment Preview

DBT Deploy to Deployment Preview

Delete Deployment Preview

Deploy to Original Deployment

About

Resources

Stars

Watchers

Forks

Releases

Packages

Used by

Contributors

Languages

Deploying on changes outside `root-folder`