Enhancement: Support the config parameter called depth

[hadiulla]

Release tags to only folders of depth defined and do not add tags for subdirectories.
Suppose i provide depth:1 it means I want to tag and release only folders till depth1 for any changes made within that folder and its subdirectories.

Usecase:
I have a monorepo terraform supermodule.

|-module1/
|---main.tf
|---provider.tf
|---scripts/
|---submodule/
|-module2/
```'
and so on..
If I make any change in submodule directory within module1, I want to release module1 only. Right now it tags and release all folders.

[virgofx]

Hi @hadiulla .

I recently added the module-path-ignore flag to provide more explicit granularity for filtering which will accomplish the similar depth request.

https://github.com/techpivot/terraform-module-releaser?tab=readme-ov-file#understanding-the-filtering-options

Did you try adding this flag in your code? In your specific example above, you should be able to specifically achieve your desired result using something similar to this:

module-path-ignore = "module1/submodule/**"

Let me know if that works?

Additionally, I think depth is potentially a good flag option also. It's a little different from the existing filtering, so I'll need to add some more documentation around the concept if we add it.

[developer2048]

Hi @virgofx ,

Does a change in path module1/submodule/** results in a new version of module1? I suppose, that is what @hadiulla wants to achieve... (We have the same problem, described in #195 ). Thanks for your help!

[luis-garza]

Yes! The depth setting is also a feature I was looking for.
I would like to have it available... 🤞

[virgofx]

I think this is a valid request that several users seem to need.

Right now, we have the ability to:

1. Filter modules completely from being versioned (via module-path-ignore)
2. Exclude specific files/paths from impacting a parent module (via module-change-exclude-patterns)

What we're missing is handling the case where you want changes in a CHILD module to force a release in a PARENT, without versioning the child itself. Is that correct?

Instead of a simple depth parameter, I'd like to propose a more flexible solution:

`nested-modules-parent-update` = A comma-separated list of parent-child module relationships in
 format "parentPattern:childPattern". When a child module changes, its parent gets updated and the
 child does not.

For your specific use case, you could use something like:

nested-modules-parent-update = "module*:module*/submodule/**"

This would ensure that when changes happen in module1/submodule/, only module1 gets versioned, not the submodule itself.
This approach gives more granular control than a simple depth parameter and works alongside our existing filtering options. Would this solution address your use case?

The reason I'm a little more in favor of this is it will provide more flexibility/granularity and avoid issues that I think a depth parameter would cause once implemented. Specifically, depth would therefore be applicable to every terraform root, potentially causing issues. Also, it's a little vague. Happy to rename the variable I suggested above to something that makes more sense or implement it differently.

@hadiulla @developer2048 @luis-garza What are your thoughts on this proposal? Would it satisfy your needs?

[developer2048]

Hi virgofx,
thanks for thinking about a solution for our problem :-) !!
The proposed solution sounds great and would provide a maximum on flexibility. A big 👍 from my side...

[luis-garza]

I was going to say that a 'comma-separated list of parent-child module relationships' would cause config management overhead, but it it supports globbing as it looks like, then it could work! 🎉

[virgofx]

Since I was more concerned with the depth being an issue in terms of confusion. Specifically, what if you wanted to release submodules directly in one parent folder but not in another. The depth parameter wouldn't be flexible enough (it would be all or nothing). Thus, since parameters are effectively strings passed through via the environment, a comma separated list was the next best approach ... unless there's a better way?

[developer2048]

@virgofx I would like to ask politely, if there are any news on this?

[virgofx]

Hi @developer2048 - I've been actively working on #202 currently. Soon as that's wrapped up I'll knock this one out. Soon :)

[developer2048]

Hi @virgofx,
may I ask politely, what is the status on this case?