👽 Terraform Orchestration Tool for DevOps. Keep environment configuration DRY with hierarchical imports of configurations, inheritance, and WAY more. Native support for Terraform and Helmfile.
"Remote State Backend" doc describes how to override Terraform Backend Configuration to access components remote state, and how to do Brownfield development in Atmos
Simplify the atmos describe affected command to not force it to clone the remote target reference (branch or tag), but instead just check it out (assuming the target reference is already on the local file system)
Add --clone-target-ref flag to the atmos describe affected command for backwards compatibility. If the flag is passed, the command behaves as the old version (clones the target reference first from the remote origin)
breaking changes
If the atmos describe affected command was used in a GitHub Action (similar to https://github.com/cloudposse/github-action-atmos-affected-stacks), and the action performed a shallow Git clone (instead of a deep clone), it will break with an error that the target reference (branch) does not exist on the file system. There are a few ways to fix it:
Use the flag --clone-target-ref=true to force the command to clone the target reference from the remote origin (this flag is addd for backwards compatibility)
atmos describe affected --clone-target-ref=true
Update the GitHub Action to perform a deep-clone instead of a shallow-clone
- uses: actions/checkout@v4
with:
fetch-depth: 0
Perform a clone of the target branch into a separate directory and use the --repo-path=<dir> command line parameter to specify the path to the already cloned target repository (refer to https://atmos.tools/cli/commands/describe/affected#flags)
description
The atmos describe affected command uses two different Git commits to produce a list of affected Atmos components and stacks.
For the first commit, the command assumes that the current repo root is a Git checkout. An error will be thrown if the
current repo is not a Git repository (the .git/ folder does not exist or is configured incorrectly).
The second commit can be specified on the command line by using the --ref (Git References) or --sha (commit SHA) flags. The --sha takes precedence over the --ref flag.
How does it work?
The command performs the following:
If the --repo-path flag is passed, the command uses it as the path to the already cloned target repo with which to compare the current working branch. I this case, the command will not clone and checkout the target reference, but instead will use the already cloned one to compare the current branch with. In this case, the --ref, --sha, --ssh-key and --ssh-key-password flags are not used, and an error will be thrown if the --repo-path flag and any of the --ref, --sha, --ssh-key or --ssh-key-password flags are provided at the same time
Otherwise, if the --clone-target-ref=true flag is specified, the command clones (into a temp directory) the remote target with which to compare the current working branch. If the --ref flag or the commit SHA flag --sha are provided, the command uses them to clone and checkout the remote target. Otherwise, the HEAD of the remote origin is used (refs/remotes/origin/HEAD Git ref, usually the main branch)
Otherwise, (if the --repo-path and --clone-target-ref=true flags are not passed), the command does not clone anything from the remote origin, but instead just copies the current repo into a temp directory and checks out the target reference with which to compare the current working branch. If the --ref flag or the commit SHA flag --sha are provided, the command uses them to check out. Otherwise, the HEAD of the remote origin is used (refs/remotes/origin/HEAD Git ref, usually the main branch). This requires that the target reference is already cloned by Git, and the information about it exists in the .git directory (in case of using a non-default branch as the target, Git deep clone needs to be executed instead of a shallow clone). This is the recommended way to execute the atmos describe affected command since it allows working with private repositories without providing the SSH credentials (--ssh-key and --ssh-key-password flags), since in this case Atmos does not access the remote origin and instead just checks out the target reference (which is already on the local file system)
The command deep-merges all stack configurations from both sources: the current working branch and the target reference
The command searches for changes in the component directories
The command compares each stack manifest section of the stack configurations from both sources looking for differences
And finally, the command outputs a JSON or YAML document consisting of a list of the affected components and stacks and what caused it to be affected
what
Update
atmos describe affectedcommandAdd
--clone-target-refflag to theatmos describe affectedcommandUpdate docs. Add "Remote State Backend" doc
why
"Remote State Backend" doc describes how to override Terraform Backend Configuration to access components remote state, and how to do Brownfield development in Atmos
Simplify the
atmos describe affectedcommand to not force it to clone the remote target reference (branch or tag), but instead just check it out (assuming the target reference is already on the local file system)Add
--clone-target-refflag to theatmos describe affectedcommand for backwards compatibility. If the flag is passed, the command behaves as the old version (clones the target reference first from the remote origin)breaking changes
If the
atmos describe affectedcommand was used in a GitHub Action (similar to https://github.com/cloudposse/github-action-atmos-affected-stacks), and the action performed a shallow Git clone (instead of a deep clone), it will break with an error that the target reference (branch) does not exist on the file system. There are a few ways to fix it:--clone-target-ref=trueto force the command to clone the target reference from the remote origin (this flag is addd for backwards compatibility)atmos describe affected --clone-target-ref=trueUpdate the GitHub Action to perform a deep-clone instead of a shallow-clone
Perform a clone of the target branch into a separate directory and use the
--repo-path=<dir>command line parameter to specify the path to the already cloned target repository (refer to https://atmos.tools/cli/commands/describe/affected#flags)description
The
atmos describe affectedcommand uses two different Git commits to produce a list of affected Atmos components and stacks.For the first commit, the command assumes that the current repo root is a Git checkout. An error will be thrown if the current repo is not a Git repository (the
.git/folder does not exist or is configured incorrectly).The second commit can be specified on the command line by using the
--ref(Git References) or--sha(commit SHA) flags. The--shatakes precedence over the--refflag.How does it work?
The command performs the following:
If the
--repo-pathflag is passed, the command uses it as the path to the already cloned target repo with which to compare the current working branch. I this case, the command will not clone and checkout the target reference, but instead will use the already cloned one to compare the current branch with. In this case, the--ref,--sha,--ssh-keyand--ssh-key-passwordflags are not used, and an error will be thrown if the--repo-pathflag and any of the--ref,--sha,--ssh-keyor--ssh-key-passwordflags are provided at the same timeOtherwise, if the
--clone-target-ref=trueflag is specified, the command clones (into a temp directory) the remote target with which to compare the current working branch. If the--refflag or the commit SHA flag--shaare provided, the command uses them to clone and checkout the remote target. Otherwise, theHEADof the remote origin is used (refs/remotes/origin/HEADGit ref, usually themainbranch)Otherwise, (if the
--repo-pathand--clone-target-ref=trueflags are not passed), the command does not clone anything from the remote origin, but instead just copies the current repo into a temp directory and checks out the target reference with which to compare the current working branch. If the--refflag or the commit SHA flag--shaare provided, the command uses them to check out. Otherwise, theHEADof the remote origin is used (refs/remotes/origin/HEADGit ref, usually themainbranch). This requires that the target reference is already cloned by Git, and the information about it exists in the.gitdirectory (in case of using a non-default branch as the target, Git deep clone needs to be executed instead of a shallow clone). This is the recommended way to execute theatmos describe affectedcommand since it allows working with private repositories without providing the SSH credentials (--ssh-keyand--ssh-key-passwordflags), since in this case Atmos does not access the remote origin and instead just checks out the target reference (which is already on the local file system)The command deep-merges all stack configurations from both sources: the current working branch and the target reference
The command searches for changes in the component directories
The command compares each stack manifest section of the stack configurations from both sources looking for differences
And finally, the command outputs a JSON or YAML document consisting of a list of the affected components and stacks and what caused it to be affected