A way to release internal dependencies automatically

[ivangonzalezz]

Hi!

We saw this GH Action and it's really nice for our use case. The only thing that I don't see covered is managing releases for internal module dependencies.

I'll explain our use case with an example.

We save all our modules in modules/ directory. We have a module called dog with the following main.tf content:

# modules/dog/main.tf
output "sound" {
    value = "Wof!"
}

And then another module called animal:

# modules/animal/main.tf
module "dog" {
    source = "../dog"
}

output "dog_sound" {
    value = module.dog.sound
}

Our expected behaviours are:

• When we update the animal module, bump its version to a new one as it's done by the Action right now.
• If we update dog module, as animal is dependent on dog locally, we expect both of them to be released, not only dog as it's done now by the Action.

We are referencing these modules locally to facilitate the TF module developer its tasks, having locally the correct version for each dependency and not having to update versions manually or in multiple PRs.

What do you think about this feature?

TY in advance!

[virgofx]

Hi @ivangonzalezz . Great idea and a solid use case. There are quite a few module/local reference trees out there in the wild in use and it makes sense. I'm going to take a stab at getting this working for you and will keep you posted. Great request!

[luis-garza]

Yeah! It would be a really nice feature!

Please, consider supporting multiple level of dependencies, I mean, a local dependency of another local dependency, and so... 🙏

[virgofx]

Great point. My thought is that during the building of the trees that map all the commits, I'll also build a dependency tree of say up to X levels (easily configurable).

The only question is if we have sub-module that updates with numerous commits -- and one is a major (e.g. major: commit message), the default would be to have this sub-module go from v1.0.0 to v2.0.0.

For a parent module that references this exact sub-module which went through a major bump, how should we handle the parent module version bump?

1. Always just bump the parent via patch (e.g. v3.0.0 --> 3.0.1)
2. Bump this version based on the version detected in the sub-module -- either patch, minor, or major.

My recommendation would be to do Number 1 as I believe potentially bumping dependent parents higher might be a little confusing. Since it's a child module, a patch seems fine.

Curious as to your thoughts?

[ivangonzalezz]

I would go to the only patch solution too.

If you need to do some changes in the parent module due to the new sub-module version, then you would add some commits for that and bump either a minor or major when required.

[luis-garza]

For a parent module that references this exact sub-module which went through a major bump, how should we handle the parent module version bump?

Yes, that's a really good point!
Right now I'm solving the local dependencies gap by adding submodule content hash as an additional conventional commit using patch level.

As @ivangonzalezz mentions, if one have to update the parent modules dir to a new sub module version, then some minor or major commits would be required in the git history...

Despite the default patch behaviour for the parent modules... Maybe would be interesting add a new parameter to define how local dependencies should be treated:

• Force to patch
• Force to minor
• Force to major
• Use submodule change level

How do you see it? 🤔