How to deal with depends_on when the dependency creates a resource for the dependant project

[edwin-bruurs]

I have the situation where I have two projects, where one of these projects depends on the other.

My atlantis.yaml looks something like this;

version: 3
parallel_plan: true
parallel_apply: false
projects:
  - name: parent
    branch: /main/
    dir: modules/parent
    workspace: default
    autoplan:
      enabled: true
      when_modified:
        - '*.tf'
  - name: child
    branch: /main/
    dir: modules/child
    workspace: default
    autoplan:
      enabled: true
      when_modified:
        - '*.tf'
    depends_on:
      - parent

My parent module generaties some global resources which my child module depends on (using a data object in Terraform).

In some cases I create a new global resource and updates my child module to use it in one single pull request. Unfortunatly atlantis fails in this case, as the plan of my child project fails as it can't read the global resource created by my parent module. On the other hand I can't use atlantis plan -p parent followed by atlantis apply -p parent as this results in the error Apply Failed: Pull request must be mergeable before running apply.. Any suggestions on how to manage this kind of dependencies?

[dosubot]

Hi @edwin-bruurs! I'm Dosu and I’m helping the atlantis team.

Atlantis uses the depends_on field in atlantis.yaml to enforce the order of planning and applying projects, but it doesn't automatically trigger plans for dependent projects or handle staged applies within a single PR. When you create a new resource in the parent and reference it in the child in the same PR, the child project's plan fails because the resource doesn't exist in the remote state yet—Terraform data sources require the resource to be present in state before they can be read during plan. Atlantis also requires the PR to be mergeable before running apply, which blocks partial or staged applies in a single PR source.

The common workaround is to apply the parent project first (so its state is updated), then re-plan and apply the child project. This usually means running atlantis apply twice: the first apply updates the parent, and the second allows the child to succeed once the parent's state is available. This is a manual process and can be error-prone source.

Best practices to minimize manual steps include splitting changes into separate PRs (apply the parent first, then update the child), or using external orchestration/CI pipelines to automate multi-step applies. Some users also leverage Terragrunt for more advanced orchestration, but Atlantis itself does not natively support automatic staged applies or re-planning dependent projects after a dependency is applied source.

There are ongoing discussions in the Atlantis community about improving depends_on to better support global apply order and staged applies, but no recent features have addressed this workflow yet source. For now, manual sequencing or external automation are the main options.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}