Skip to main content
Sponsor @cloudposse

Frequently Asked Questions

What are the included labels?​

By default, Cloud Posse includes a few labels for common use-cases.

Pull Request Labels​

  1. auto-apply - If added, the Atmos Terraform Apply workflow will be triggered for all affected components when the Pull Request is merged.
  2. no-plan - If added, the Atmos Terraform Plan workflow will be skipped on commits to the Pull Request, and the Atmos Apply workflow will be skipped when the Pull Request is merged.

Issue Labels​

  • apply - Triggers the Atmos Terraform Drift Remediation workflow for a specific component and stack
  • discarded - Issue was closed by the drift detection workflow
  • drift - Indicates that drift was detected by the drift detection workflow
  • drift-recovered - Indicates that an issue is no longer experiencing drift
  • error - Indicates an error occurred during planning for a specific component and stack
  • error-recovered - Indicates that an error state has been resolved
  • remediated - Issue was successfully remediated by the drift remediation action
  • removed - Issue is closed because the component no longer exists (code was deleted)

Enabling or disabling components​

Components are included in the Atmos GitHub Action workflows only if they have actions enabled with the terraform.settings.github.actions_enabled option.

If they do not have this setting or the value is false, the component may still appear in the list of affected components, but Terraform will not be run against the given component and stack.

Global Defaults

Typically Cloud Posse sets the default value to true for all components and disables individual components on a case-by-case basis.

For example in an acme organization, the default value could be set with stacks/orgs/acme/_defaults.yaml:

terraform:
  # These settings are applied to ALL components by default but can be overwritten
  settings:
    github:
      actions_enabled: true

And the account component could be disabled with stacks/catalog/account.yaml:

components:
  terraform:
    account:
      settings:
        github:
          actions_enabled: false

I cannot assume the gitops role from GitHub Workflows​

The following error commonly occurs when setting up gitops roles and permission:

Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

To resolve this error, thoroughly read through each of the Authentication Prerequisites for GitOps setup. In particular, check the capitalization of trusted_github_repos within aws-teams and check the permissions for the workflow in GitHub.

How does GitHub OIDC work with AWS?​

Please see How to use GitHub OIDC with AWS