Git sparse checkout paths on module tests

We have consolidated our modules into one git repo and are using sparse checkout paths. However, our resources are split across separate modules. As an example we have three separate modules:

- `terraform-azure-sqlserver`
- `terraform-azure-sqlelasticpooldb`
- `terraform-azure-sqlserverdb`

When I test the `sqlserverdb` module, I need the server and elastic pool modules available. Historically we've referenced the Spacelift registry version of the sister module in the test stack. This worked fine, but now we're doing a big bang azurerm v3 → v5 upgrade and testing fails due to the provider dependency conflict described above.

Workaround

Problem

When using a monorepo with sparse checkout paths, module tests that depend on sister modules can only reference them via the Spacelift registry. This works under normal conditions, but breaks during coordinated breaking changes (e.g. a major provider upgrade) because: 1. The test stack declares the new provider version (e.g. ~> 5.0) 2. The sister module downloaded from the registry still carries the old constraint (e.g. ~> 3.0, < 4.0.0) 3. Terraform aggregates all constraints and fails — no version satisfies both This creates a chicken-and-egg problem: we can't test until the dependencies are published with the new constraints, and we can't publish until the tests pass. The only workaround today is to disable tests, merge blind, publish, then re-enable — which defeats the purpose of having tests. We could include the additional to the module but i don't really want all that extra tf downloaded when i may not actually use it if that makes sense

Please authenticate to join the conversation.

Upvoters

Status

👀 In Review

Board

💡 Feature Requests

Subscribe to post