### Simplify Workflow Dispatches with YAML Anchors

Source: https://atmos-pro.com/docs/configure/atmos

This example shows how to use YAML anchors to reduce verbosity when configuring workflow dispatches. It defines reusable anchor configurations for plan and apply workflows, making the main settings section cleaner.

```yaml
plan-wf-config: &plan-wf-config
  atmos-terraform-plan.yaml:
    inputs:
      component: "{{ .atmos_component }}"
      stack: "{{ .atmos_stack }}"
 
apply-wf-config: &apply-wf-config
  atmos-terraform-apply.yaml:
    inputs:
      component: "{{ .atmos_component }}"
      stack: "{{ .atmos_stack }}"
 
settings:
  pro:
    enabled: true
    pull_request:
      opened:
        workflows: *plan-wf-config
      synchronize:
        workflows: *plan-wf-config
      reopened:
        workflows: *plan-wf-config
      merged:
        workflows: *apply-wf-config
```

--------------------------------

### Development Workflow Permissions Example

Source: https://atmos-pro.com/docs/learn/permissions

This configuration allows any workflow from main, develop, or feature branches to report affected stacks. It demonstrates a broad permission setting for development environments.

```hcl
Permission: Affected Stacks Create
Workflow: "*"
Branch: "^(main|develop|feature/.*)$"
Environment: "*"
```

--------------------------------

### Define Component Dependencies using YAML

Source: https://atmos-pro.com/docs/configure/atmos

This YAML snippet demonstrates how to define dependencies between components like 'api', 'frontend', and 'cdn' using the `settings.depends_on` section. It specifies which components must be deployed before others, ensuring a correct deployment order.

```yaml
components:
  terraform:
    api:
      settings:
        depends_on:
          "1":
            component: "database"
          "2":
            component: "cluster"
    frontend:
      settings:
        depends_on:
          "1":
            component: "api"
          "2":
            component: "cache"
    cdn:
      settings:
        depends_on:
          "1":
            component: "object-storage"
          "2":
            component: "frontend"

```

--------------------------------

### Import Atmos Pro Mixin into Stack Configuration

Source: https://atmos-pro.com/docs/configure/atmos

Demonstrates how to import the 'atmos-pro' mixin into a specific stack configuration file. This applies the default Atmos Pro settings to that stack.

```yaml
import:
  - mixins/atmos-pro
```

--------------------------------

### Configure GitHub OIDC Authentication for Atmos Pro

Source: https://atmos-pro.com/docs/configure/github-workflows

This snippet shows how to configure a GitHub Actions workflow to use OIDC authentication with Atmos Pro. It requires setting up repository permissions for OIDC and reading contents, and uses environment variables for the Atmos Pro Workspace ID and Atmos version. The `cloudposse/github-action-atmos-affected-stacks@v6` action is used to determine affected stacks.

```yaml
.github/workflows/affected-stacks.yaml
jobs:
  affected:
    name: Determine Affected Stacks
    runs-on:
      - "ubuntu-latest"
    permissions:
      id-token: write # Required for OIDC
      contents: read # Required for checking out code
    steps:
      - name: Determine Affected Stacks
        id: affected
        uses: cloudposse/github-action-atmos-affected-stacks@v6
        env:
          ATMOS_PRO_WORKSPACE_ID: ${{ vars.ATMOS_PRO_WORKSPACE_ID }} # Your workspace ID from Atmos Pro
        with:
          atmos-version: ${{ vars.ATMOS_VERSION }} # >= 1.180.0
          atmos-config-path: ${{ vars.ATMOS_CONFIG_PATH }}
          atmos-pro-upload: true
          head-ref: ${{ github.event.pull_request.head.sha }}

```

--------------------------------

### Configure GitHub Integration for Atmos CLI

Source: https://atmos-pro.com/docs/deploy/cloud-integrations

Configures the GitHub integration within the Atmos CLI, specifying OpenTofu version, artifact storage details (region, bucket, table), and IAM roles for plan and apply actions. Ensure the region matches the CloudFormation deployment.

```yaml
integrations:
  github:
    gitops:
      opentofu-version: "1.10.0"
      artifact-storage:
        region: "us-east-1" # Ensure this matches the region where the template was deployed
        bucket: "my-backend-tfplan" # Get this value from the PlanBucketName output
        table: "my-backend-tfplan" # Get this value from the PlanDynamoDBTableName output
        role: "arn:aws:iam::123456789012:role/my-backend-github-actions" # Get this value from the GitHubActionsRoleARN output
      role:
        plan: "arn:aws:iam::123456789012:role/my-backend-github-actions" # Get this value from the GitHubActionsRoleARN output
        apply: "arn:aws:iam::123456789012:role/my-backend-github-actions" # Get this value from the GitHubActionsRoleARN output
```

--------------------------------

### Deploy AWS CloudFormation Backend Infrastructure with AWS CLI

Source: https://atmos-pro.com/docs/deploy/cloud-integrations

Deploys the complete Terraform backend infrastructure for Atmos Pro in a single CloudFormation stack using the AWS CLI. This includes state backend, plan file storage, and GitHub Actions OIDC integration. Ensure your stack name is unique.

```bash
aws cloudformation deploy \
  --stack-name my-backend \
  --template-url https://s3.amazonaws.com/cplive-core-ue2-public-cloudformation/aws-cloudformation-terraform-backend.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --no-fail-on-empty-changeset \
  --parameter-overrides GitHubOrg=my-org
```

--------------------------------

### Configure Workflow Triggers with workflow_dispatch

Source: https://atmos-pro.com/docs/configure/github-workflows

This YAML snippet demonstrates how to configure a GitHub Actions workflow to be triggered by Atmos Pro using the `workflow_dispatch` event. This allows Atmos Pro to control the execution order and timing of workflows based on stack configurations.

```yaml
on:
  workflow_dispatch:

```

--------------------------------

### Define Required Inputs for Atmos Pro Workflows

Source: https://atmos-pro.com/docs/configure/github-workflows

This YAML snippet defines the necessary inputs for a GitHub Actions workflow that is dispatched by Atmos Pro. It includes required inputs like `atmos_pro_run_id` and `sha`, along with `component` and `stack`. These inputs are crucial for Atmos Pro to correctly identify and execute the workflow.

```yaml
on:
  workflow_dispatch:
    inputs:
      atmos_pro_run_id:
        description: "Atmos Pro Run ID"
        type: string
      sha:
        description: "Commit SHA"
        type: string
      component:
        description: "Component"
        required: true
        type: string
      stack:
        description: "Stack"
        required: true
        type: string

```

--------------------------------

### Enable Atmos Pro Feature

Source: https://atmos-pro.com/docs/configure/atmos

This snippet shows how to enable the Atmos Pro feature within your Atmos configuration. It involves setting a boolean flag in the 'settings.pro' section of your YAML configuration.

```yaml
settings:
  pro:
    enabled: true
```

--------------------------------

### GitHub Actions: Atmos Pro Affected Stacks Workflow

Source: https://atmos-pro.com/docs/deploy/terraform

This workflow determines which Atmos Pro stacks are affected by changes in a pull request or push to the main branch. It uses the `cloudposse/github-action-atmos-affected-stacks` action and requires GitHub Actions familiarity. It outputs the affected stacks for subsequent workflows.

```yaml
name: "👽 Atmos Pro Determine Affected Stacks"
run-name: "👽 Atmos Pro Determine Affected Stacks"

# Atmos Pro reacts to events defined in the Atmos stack settings
# and will trigger the appropriate workflows for the given event.
#
# For example, pull requests opened, synchronize, and reopened will trigger plan workflows.
# Whereas pull requests merged will trigger apply workflows
on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
      - closed
    branches:
      - main

# Avoid conflicting workflow triggers.
# For example, wait to trigger apply until plan has been triggered
concurrency:
  group: "${{ github.ref }}"
  cancel-in-progress: false

permissions:
  id-token: write # This is required for requesting the JWT (OIDC) token
  contents: read # This is required for actions/checkout

jobs:
  affected:
    name: Trigger Affected Stacks

    runs-on:
      - "ubuntu-latest"

    # Trigger Atmos Pro for Pull Request plan events and specifically closed PRs that have been merged (not just closed)
    if: github.event.action != 'closed' || (github.event.action == 'closed' && github.event.pull_request.merged == true)

    steps:
      - name: Checkout
        # For merged PRs, we will need to checkout the base branch to get the correct base branch SHA.
        # This isn't necessary for other events.
        if: github.event.action == 'closed'
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Fetch all history for all branches and tags

      # For merged PRs, we want to use 1 previous commit from the base branch SHA
      # This is because by the time this workflow runs, the PR branch has already been merged.
      # It's critical to use the base branch SHA to get the correct changes, not the previous commit from the PR branch.
      - name: Determine previous commit on base branch
        id: get_parent
        if: github.event.action == 'closed'
        shell: bash
        run: |
          # For squash merges, github.event.pull_request.base.sha represents the state of the base branch
          # when the PR was created (or last updated). This may be stale compared to the actual commit
          # on the main branch at the time of the merge. Using 'HEAD~1' after the merge ensures we get
          # the commit that was the tip of main immediately before the squash merge commit was added.
          echo "Merge commit: $(git rev-parse HEAD)"
          PARENT=$(git rev-parse HEAD~1)
          echo "Parent (base) commit: $PARENT"
          echo "merge_commit=$MERGE_COMMIT" >> "$GITHUB_OUTPUT"
          echo "parent_commit=$PARENT" >> "$GITHUB_OUTPUT"

      - name: Determine Affected Stacks
        id: affected
        uses: cloudposse/github-action-atmos-affected-stacks@v6
        env:
          ATMOS_PRO_WORKSPACE_ID: ${{ vars.ATMOS_PRO_WORKSPACE_ID }}
        with:
          atmos-version: ${{ vars.ATMOS_VERSION }} # >= 1.180.0
          atmos-config-path: ${{ vars.ATMOS_CONFIG_PATH }}
          atmos-pro-upload: true
          # Compare the head of the PR to the base of the PR if the PR is not merged.
          # If the PR is merged, compare the head of the PR to 1 previous commit on the base branch.
          head-ref: ${{ github.event.pull_request.head.sha }}
          base-ref: ${{ github.event.action == 'closed' && steps.get_parent.outputs.parent_commit || github.event.pull_request.base.sha }}

```

--------------------------------

### Configure Workflow Dispatches for Pull Requests

Source: https://atmos-pro.com/docs/configure/atmos

This configuration defines the workflows that Atmos Pro should trigger based on pull request events. It specifies which YAML workflow files to dispatch and their corresponding inputs for different PR states (opened, synchronized, reopened, merged).

```yaml
settings:
  pro:
    enabled: true
    pull_request:
      opened:
        workflows:
          atmos-terraform-plan.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
      synchronize:
        workflows:
          atmos-terraform-plan.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
      reopened:
        workflows:
          atmos-terraform-plan.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
      merged:
        workflows:
          atmos-terraform-apply.yaml:
            inputs:
              component: "{{ .atmos_component }}"
              stack: "{{ .atmos_stack }}"
```

--------------------------------

### Configure Workflow Run Name for Plan Workflows (GitHub Actions)

Source: https://atmos-pro.com/docs/configure/github-workflows

Sets a deterministic `run-name` for GitHub Actions workflows triggered by Atmos Pro for plan operations. This ensures Atmos Pro can consistently update the correct status comment.

```yaml
name: 👽 Atmos Pro Terraform Plan
run-name: plan ${{ inputs.component }}/${{ inputs.stack }}/${{ inputs.atmos_pro_run_id}}
```

--------------------------------

### Configure Terraform State Backend for Atmos CLI

Source: https://atmos-pro.com/docs/deploy/cloud-integrations

Configures the Terraform state backend using S3 and DynamoDB within the Atmos CLI. Specifies bucket names, DynamoDB table names, and encryption settings. Set `role_arn` to null to use current AWS credentials.

```yaml
terraform:
  backend_type: s3
  backend:
    s3:
      bucket: my-backend-tfstate # Get this value from the StateBucketName output
      dynamodb_table: my-backend-tfstate # Get this value from the StateDynamoDBTableName output
      role_arn: null # Set to null to use the current AWS credentials
      encrypt: true
      key: terraform.tfstate
      acl: bucket-owner-full-control
      region: us-east-1 # Ensure this matches the region where the template was deployed
  remote_state_backend:
    s3:
      role_arn: null # Set to null to use the current AWS credentials
```

--------------------------------

### Configure Workflow Run Name for Apply Workflows (GitHub Actions)

Source: https://atmos-pro.com/docs/configure/github-workflows

Sets a deterministic `run-name` for GitHub Actions workflows triggered by Atmos Pro for apply operations. This ensures Atmos Pro can consistently update the correct status comment.

```yaml
name: 👽 Atmos Pro Terraform Apply
run-name: apply ${{ inputs.component }}/${{ inputs.stack }}/${{ inputs.atmos_pro_run_id}}
```

--------------------------------

### Pass Atmos Pro Workspace ID as Environment Variable (GitHub Actions)

Source: https://atmos-pro.com/docs/configure/github-workflows

Passes the Atmos Pro workspace ID as an environment variable to GitHub Actions workflows. This ID is crucial for Atmos Pro to identify the correct workspace context and for secure OIDC authentication.

```yaml
env:
  ATMOS_PRO_WORKSPACE_ID: ${{ vars.ATMOS_PRO_WORKSPACE_ID }} # Your workspace ID from Atmos Pro
```

--------------------------------

### Destroy AWS CloudFormation Stack with AWS CLI

Source: https://atmos-pro.com/docs/deploy/cloud-integrations

Commands to destroy the CloudFormation stack created for Atmos Pro backend infrastructure. The first command attempts a standard deletion, while the second uses `FORCE_DELETE_STACK` to empty S3 buckets, which is a destructive and irreversible action.

```bash
aws cloudformation delete-stack --stack-name my-backend
```

```bash
aws cloudformation delete-stack --stack-name my-backend --deletion-mode FORCE_DELETE_STACK
```

--------------------------------

### Lock a Deployment with Atmos CLI

Source: https://atmos-pro.com/docs/configure/deployment-locking

Use the Atmos CLI to lock a specific deployment stack, preventing other workflows from running on it. The lock has a time-to-live (TTL) and can include a message for concurrent attempts. This ensures exclusive access for the current workflow.

```bash
atmos pro lock <key> --ttl <ttl> --message <message>
```

--------------------------------

### Unlock a Deployment with Atmos CLI

Source: https://atmos-pro.com/docs/configure/deployment-locking

Release a previously locked deployment stack using the Atmos CLI. This allows new workflows to be dispatched to the stack. It can also be used to forcefully unlock a deployment before its TTL expires.

```bash
atmos pro unlock <key>
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.