atmos describe dependents
Use this command to show a list of Atmos components in Atmos stacks that depend on the provided Atmos component.
Description​
In Atmos, you can define component dependencies by using the settings.depends_on
section. The section used to define
all the Atmos components (in the same or different stacks) that the current component depends on.
The settings.depends_on
section is a map of objects. The map keys are just the descriptions of dependencies and can be strings or numbers.
Provide meaningful descriptions so that people can understand what the dependencies are about.
Each object in the settings.depends_on
section has the following schema:
- file (optional)
- A file on the local filesystem that the current component depends on
- folder (optional)
- A folder on the local filesystem that the current component depends on
- component (required if
file
orfolder
is not specified) - an Atmos component that the current component depends on
- namespace (optional)
- The
namespace
where thecomponent
is provisioned - tenant (optional)
- The
tenant
where thecomponent
is provisioned - environment (optional)
- The
environment
where thecomponent
is provisioned - stage (optional)
- The
stage
where thecomponent
is provisioned
One of component
, file
or folder
is required.
Dependencies on external files (not in the component's folder) are defined using the file
attribute. For example:
components:
terraform:
top-level-component3:
metadata:
component: "top-level-component1"
settings:
depends_on:
1:
file: "examples/tests/components/terraform/mixins/introspection.mixin.tf"
In the configuration above, we specify that the Atmos component top-level-component3
depends on the file
examples/tests/components/terraform/mixins/introspection.mixin.tf
(which is not in the component's folder).
Dependencies on external folders are defined using the folder
attribute. For example:
components:
terraform:
top-level-component3:
metadata:
component: "top-level-component1"
settings:
depends_on:
1:
file: "examples/tests/components/terraform/mixins/introspection.mixin.tf"
2:
folder: "examples/tests/components/helmfile/infra/infra-server"
In the configuration above, we specify that the Atmos component top-level-component3
depends on the folder
examples/tests/components/helmfile/infra/infra-server
.
If component
is specified, the rest of the attributes are the context variables and are used to define Atmos stacks other than the current stack.
For example, you can specify:
namespace
if thecomponent
is from a different Organizationtenant
if thecomponent
is from a different Organizational Unitenvironment
if thecomponent
is from a different regionstage
if thecomponent
is from a different accounttenant
,environment
andstage
if the component is from a different Atmos stack (e.g.tenant1-ue2-dev
)
In the following example, we define that the top-level-component1
component depends on the following:
- The
test/test-component-override
component in the same Atmos stack - The
test/test-component
component in Atmos stacks identified by thedev
stage - The
my-component
component from thetenant1-ue2-staging
Atmos stack
components:
terraform:
top-level-component1:
settings:
depends_on:
1:
# If the `context` (namespace, tenant, environment, stage) is not provided,
# the `component` is from the same Atmos stack as this component
component: "test/test-component-override"
2:
# This component (in any stage) depends on `test/test-component`
# from the `dev` stage (in any `environment` and any `tenant`)
component: "test/test-component"
stage: "dev"
3:
# This component depends on `my-component`
# from the `tenant1-ue2-staging` Atmos stack
component: "my-component"
tenant: "tenant1"
environment: "ue2"
stage: "staging"
vars:
enabled: true
In the following example, we specify that the top-level-component2
component depends on the following:
- The
test/test-component
component in the same Atmos stack - The
test/test2/test-component-2
component in the same Atmos stack
components:
terraform:
top-level-component2:
metadata:
# Point to Terraform component
component: "top-level-component1"
settings:
depends_on:
1:
# If the `context` (namespace, tenant, environment, stage) is not provided,
# the `component` is from the same Atmos stack as this component
component: "test/test-component"
2:
# If the `context` (namespace, tenant, environment, stage) is not provided,
# the `component` is from the same Atmos stack as this component
component: "test/test2/test-component-2"
vars:
enabled: true
Having the top-level-component
and top-level-component2
components configured as shown above, we can now execute the following Atmos command
to show all the components that depend on the test/test-component
component in the tenant1-ue2-dev
stack:
Similarly, the following Atmos command shows all the components that depend on the test/test-component
component in
the tenant1-ue2-test-1
stack:
After the test/test-component
has been provisioned, you can use the outputs to perform the following actions:
-
Provision the dependent components by executing the Atmos commands
atmos terraform apply top-level-component1 -s tenant1-ue2-test-1
andatmos terraform apply top-level-component2 -s tenant1-ue2-test-1
(on the command line or from a GitHub Action) -
Trigger the dependent Spacelift stack (from a GitHub Action by using the spacectl CLI, or by using an OPA Trigger policy, or by using the spacelift_stack_dependency resource)
-
Trigger the dependent Atlantis project
Usage​
atmos describe dependents [options]
Run atmos describe dependents --help
to see all the available options
Examples​
atmos describe dependents test/test-component -s tenant1-ue2-test-1
atmos describe dependents test/test-component -s tenant1-ue2-dev --format yaml
atmos describe dependents test/test-component -s tenant1-ue2-test-1 -f yaml
atmos describe dependents test/test-component -s tenant1-ue2-test-1 --file dependents.json
atmos describe dependents test/test-component -s tenant1-ue2-test-1 --format yaml --file dependents.yaml
Arguments​
Argument | Description | Required |
---|---|---|
component | Atmos component | yes |
Flags​
Flag | Description | Alias | Required |
---|---|---|---|
--stack | Atmos stack | -s | yes |
--format | Output format: json or yaml (json is default) | -f | no |
--file | If specified, write the result to the file | no |
Output​
The command outputs a list of objects (in JSON or YAML format).
Each object has the following schema:
{
"component": "....",
"component_type": "....",
"component_path": "....",
"namespace": "....",
"tenant": "....",
"environment": "....",
"stage": "....",
"stack": "....",
"stack_slug": "",
"spacelift_stack": ".....",
"atlantis_project": "....."
}
where:
-
component
- the dependent Atmos component -
component_type
- the type of the dependent component (terraform
orhelmfile
) -
component_path
- the filesystem path to theterraform
orhelmfile
component -
namespace
- thenamespace
where the dependent Atmos component is provisioned -
tenant
- thetenant
where the dependent Atmos component is provisioned -
environment
- theenvironment
where the dependent Atmos component is provisioned -
stage
- thestage
where the dependent Atmos component is provisioned -
stack
- the Atmos stack where the dependent Atmos component is provisioned -
stack_slug
- the Atmos stack slug (concatenation of the Atmos stack and Atmos component) -
spacelift_stack
- the dependent Spacelift stack. It will be included only if the Spacelift workspace is enabled for the dependent Atmos component in the Atmos stack in thesettings.spacelift.workspace_enabled
section (either directly in the component'ssettings.spacelift.workspace_enabled
section or via inheritance) -
atlantis_project
- the dependent Atlantis project name. It will be included only if the Atlantis integration is configured in thesettings.atlantis
section in the stack manifest. Refer to Atlantis Integration for more details
Abstract Atmos components (metadata.type
is set to abstract
) are not included in the output since they serve as blueprints for other
Atmos components and are not meant to be provisioned.