In April 2024, the Core Atlantis Team launched an anonymous survey to better understand our community's needs and help prioritize our roadmap.
If you're an Atlantis user, please take 5 minutes to fill it out: Survey Link
In April 2024, the Core Atlantis Team launched an anonymous survey to better understand our community's needs and help prioritize our roadmap.
If you're an Atlantis user, please take 5 minutes to fill it out: Survey Link
You can configure how Atlantis checks out the code from your pull request via the --checkout-strategy flag or the ATLANTIS_CHECKOUT_STRATEGY environment variable that get passed to the atlantis server command.
Atlantis supports branch and merge strategies.
If set to branch (the default), Atlantis will check out the source branch of the pull request.
For example, given the following git history: 
If the pull request was asking to merge branch into main, Atlantis would check out branch at commit C3.
The problem with the branch strategy, is that if users push branches that are out of date with main, then their terraform plan could be deleting some resources that were configured in the main branch.
For example, in the above diagram if commits C4 and C5 have modified the terraform state and added new resources, then when Atlantis runs terraform plan at commit C3, because the code doesn't have the changes from C4 and C5, Terraform will try to delete those resources.
To fix this, users could merge main into their branch, or you can run Atlantis with --checkout-strategy=merge. With this strategy, Atlantis will try to perform a merge locally by:
main)git merge {source branch}In this example, the code that Atlantis would be operating on would look like: 
 Where Atlantis is using its local commit C6.
NOTE
Atlantis doesn't actually commit this merge anywhere. It just uses it locally.
WARNING
Atlantis only performs this merge during the terraform plan phase. If another commit is pushed to main after Atlantis runs plan, nothing will happen.
To optimize cloning time, Atlantis can perform a shallow clone by specifying the --checkout-depth flag. The cloning is performed in a following manner:
--checkout-depth value of zero (full clone).branch is retrieved, including the same amount of commits.branch is checked for existence in the shallow clone.--checkout-depth commits. In this case full repo history is fetched.If the commit history often diverges by more than the default checkout depth then the --checkout-depth flag should be tuned to avoid full fetches.