#spacelift (2022-04)

@

Hi @deniz gökçin!

In order to optimize the download of changes, the current implementation of the GitHub integration retrieves the source code as an archive. The unfortunate side-effect is that Git submodules are not supported.

An alternative would be to turn the shared modules into Terraform modules.

Yes, this is actually a cool pattern we have used else where and forgot about.

Basically, you can use

module "something" {
  source = "git...." # any git repo
}

And when terraform init is run, it will pull down that ref.

So you get effectively the same outcome, only it’s a terraform native solution.

Exactly.

btw, module "something" doesn’t even need to have terraform code in it. It could be anything. a microservice repo.

I have used that pattern a lot in projects. You can even point to a specific tag, branch or commit by using the ref query parameter.

module "vpc" {
  source = "git::<https://example.com/vpc.git?ref=v1.2.0>"
}

See https://www.terraform.io/language/modules/sources#selecting-a-revision

HTTPS and SSH protocols are supported to interact with GitHub.

# HTTPS
module "consul" {
  source = "github.com/hashicorp/example"
}

# SSH
module "consul" {
  source = "[email protected]:hashicorp/example.git"
}

and just to have “said it” you can also switch to using git subtrees.

Thank you for all the replies!

I believe I will have problems with my terragrunt dependencies. Let me give an example. If a resource in an app repository uses a common resource (like vpc) and I need to include a dependency like the ss below in my terragrunt.hcl. Unfortunately terragrunt does not allow the config_path to be a git url. It needs to be a path which poins to the hcl file and in my case, this is a submodule. And therefore will cause a problem.

Any suggestions?

@deniz gökçin Are you using these dependency blocks to reference outputs I’m assuming?

You could potentially store those outputs in parameter store, and reference them that way instead. Or store them into a Spacelift Context.

As far as managing dependencies for the ordering in which things run, you can use a trigger policy for doing this in Spacelift like this one: https://github.com/spacelift-io/spacelift-policies-example-library/blob/main/trigger/trigger-dependencies.rego • This trigger policy would allow you to build dependency management for ordering of deployments simply by using labels. You would attach this policy to your stacks, for example: ◦ stack-a ◦ stack-b Then you could add the label depends-on:stack-a to stack-b. Assuming the policy was attached to stack-a, this would make it so stack-b is automatically triggered after stack-a is deployed.

We have found that most Terragrunt features are easily replaced with native Spacelift features like this.

@ thanks for the reply, yes I am using the dependency blocks to get the outputs and yes, storing them in parameter store is an option.

Another option I thought before I decided to use submodules was writing a common data module which is full of data blocks and in my dependency blocks, referencing the outputs of the data module. I gave up on this after I started feeling like it would be hard to develop and maintain a common data module that might grow in the feature.

I decided to go with submodules since while it allowed me to seperate my resources from each other, I did not have to give up on any features of terragrunt like the dependency management.

So what you are saying is I need to rethink the way I am using dependencies if I want to use spacelift.

That would not work because we download an archive to optimize the initialization, unless you wipe out the workspace, provide GitHub credentials, clone the repository, and then initialize the submodules. This is quite impractical IMHO.