GitHub Event Triggers

Triggers are the events that cause Atmos Pro to dispatch workflows.

With Triggers, you can:

Automate deployments on pull_request and release events

Create sophisticated CI/CD pipelines with ordered deployments

Keep infrastructure in sync with your codebase

Run workflows manually with workflow_dispatch

Triggers are the events that cause Atmos Pro to dispatch workflows. Unlike traditional GitHub Actions workflows that respond directly to GitHub events, Atmos Pro acts as an intelligent orchestrator that listens for specific events and then dispatches workflows based on your configuration.
Atmos Pro currently supports two main types of GitHub events that can trigger workflows:

Pull Request Events

Pull request events are the most common trigger for infrastructure deployments. They allow you to:
  • Plan changes when pull requests are opened, updated, or reopened
  • Apply changes when pull requests are merged
  • Validate infrastructure during the development process
When to use pull request triggers:
  • For development workflows where you want to test infrastructure changes before merging
  • When you need to validate that infrastructure changes work correctly
  • For teams that want to review infrastructure changes through pull requests
  • When you want to ensure infrastructure is always in sync with your codebase
Each GitHub event type supports specific activity types that determine when workflows are triggered. You can find the complete list of supported pull request activity types and supported release activity types in GitHub's documentation.

Pull Request Activity Types

Atmos Pro supports all standard GitHub pull request activity types plus one custom type:

Pull Request Activity Types

opened

When a pull request is first created

synchronize

When new commits are pushed to the pull request

reopened

When a closed pull request is reopened

closed

When a pull request is closed (but not necessarily merged)

assigned

When a pull request is assigned to someone

unassigned

When a pull request assignment is removed

labeled

When a label is added to a pull request

unlabeled

When a label is removed from a pull request

locked

When a pull request is locked

unlocked

When a pull request is unlocked

review_requested

When a review is requested

review_request_removed

When a review request is removed

ready_for_review

When a draft pull request is marked ready for review

converted_to_draft

When a pull request is converted to draft

edited

When a pull request title or body is edited

milestoned

When a pull request is added to a milestone

demilestoned

When a pull request is removed from a milestone

auto_merge_enabled

When auto-merge is enabled

auto_merge_disabled

When auto-merge is disabled

enqueued

When a pull request is queued for auto-merge

dequeued

When a pull request is removed from auto-merge queue

merged

Atmos Pro specific: Triggers when a pull request is closed AND merged (not just closed)

Development Workflow Pattern

For development workflows, you typically want to plan infrastructure changes when pull requests are opened or updated, and apply those changes when the pull request is merged. This pattern allows teams to:
  • Validate changes early: Run planning workflows when pull requests are created or updated to catch issues before merging
  • Ensure safety: Only apply changes after the pull request has been reviewed and merged
  • Maintain consistency: Keep infrastructure in sync with the codebase automatically
This pattern is ideal for teams that want to test infrastructure changes during development and ensure all changes go through a proper review process.
  1. 1
    Event Detection: Atmos Pro listens for GitHub webhook events (pull requests and releases)
  2. 2
    Affected Stack Analysis: When an event occurs, Atmos Pro analyzes which stacks are affected by the changes
  3. 3
    Workflow Matching: Atmos Pro matches the event type and activity type against your configuration
  4. 4
    Ordered Dispatch: Workflows are dispatched in dependency order, ensuring parent stacks complete before child stacks
  5. 5
    Status Tracking: Atmos Pro tracks the status of all workflows and provides visibility into the deployment process

Best Practices for Using Triggers:

Use merged instead of closed for pull request deployments to ensure changes are actually applied

Plan on multiple events (opened, synchronize, reopened) to catch all changes during development

Use release triggers for production deployments to ensure they only happen on official releases

Combine triggers strategically to create different deployment patterns for different environments

Use template functions in inputs to dynamically pass stack and component information

Ready to configure triggers?

Visit the GitHub Workflows configuration page to set up triggers.

Configure NowNext: Learn about Workflow Dispatches
Deployment LockingWorkflow Dispatches