GitHub Action for Triggering Affected Spacelift Stacks

This repo contains a GitHub Action that determines the affected Atmos stacks for a PR, then creates a comment on the PR which Spacelift can use to trigger the corresponding stacks via a push policy.

Optionally, you can use the spacectl trigger method, which uses the spacectl CLI to trigger the corresponding spacelift stacks directly rather than via comment/push policy.

  name: Pull Request
  on:
    pull_request:
      branches: [ 'main' ]
      types: [opened, synchronize, reopened, closed, labeled, unlabeled]

  jobs:
    context:
      runs-on: ubuntu-latest
      steps:
        - name: Atmos Affected Stacks Trigger Spacelift (via comment)
          uses: cloudposse/github-action-atmos-affected-trigger-spacelift@main
          id: example
          with:
            atmos-config-path: ./rootfs/usr/local/etc/atmos
            github-token: ${{ secrets.GITHUB_TOKEN }}

        - name: Atmos Affected Stacks Trigger Spacelift (direct)
          uses: cloudposse/github-action-atmos-affected-trigger-spacelift@main
          id: example
          with:
            atmos-config-path: ./rootfs/usr/local/etc/atmos
            github-token: ${{ secrets.GITHUB_TOKEN }}
            trigger-method: spacectl
            spacelift-endpoint: https://unicorn.app.spacelift.io
            spacelift-api-key-id: ${{ secrets.SPACELIFT_API_KEY_ID }}
            spacelift-api-key-secret: ${{ secrets.SPACELIFT_API_KEY_SECRET }}

Check out these related projects.

For additional context, refer to some of these links.

• github-actions-workflows - Reusable workflows for different types of projects
• example-github-action-release-workflow - Example application with complicated release workflow

This project is under active development, and we encourage contributions from our community.

Many thanks to our outstanding contributors:

For 🐛 bug reports & feature requests, please use the issue tracker.

In general, PRs are welcome. We follow the typical "fork-and-pull" Git workflow.

1. Review our Code of Conduct and Contributor Guidelines.
2. Fork the repo on GitHub
3. Clone the project to your own machine
4. Commit changes to your own branch
5. Push your work back up to your fork
6. Submit a Pull Request so that we can review your changes

NOTE: Be sure to merge the latest changes from "upstream" before making a pull request!

Join our Open Source Community on Slack. It's FREE for everyone! Our "SweetOps" community is where you get to talk with others who share a similar vision for how to rollout and manage infrastructure. This is the best place to talk shop, ask questions, solicit feedback, and work together as a community to build totally sweet infrastructure.

Sign up for our newsletter and join 3,000+ DevOps engineers, CTOs, and founders who get insider access to the latest DevOps trends, so you can always stay in the know. Dropped straight into your Inbox every week — and usually a 5-minute read.

Join us every Wednesday via Zoom for your weekly dose of insider DevOps trends, AWS news and Terraform insights, all sourced from our SweetOps community, plus a live Q&A that you can’t find anywhere else. It's FREE for everyone!

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  https://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

All other trademarks referenced herein are the property of their respective owners.

Copyright © 2017-2025 Cloud Posse, LLC