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.
- 1Event Detection: Atmos Pro listens for GitHub webhook events (pull requests and releases)
- 2Affected Stack Analysis: When an event occurs, Atmos Pro analyzes which stacks are affected by the changes
- 3Workflow Matching: Atmos Pro matches the event type and activity type against your configuration
- 4Ordered Dispatch: Workflows are dispatched in dependency order, ensuring parent stacks complete before child stacks
- 5Status 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
merged
instead of closed
for pull request deployments to ensure changes are actually appliedPlan on multiple events (opened
, synchronize
, reopened
) to catch all changes during development
opened
, synchronize
, reopened
) to catch all changes during developmentUse 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.