feat: Add recursive directory check for --restrict-file-list #4972
Conversation
ibalat
requested review from
GenPage,
lukemassa and
nitrocode
and removed request for
a team
| @@ -629,8 +629,10 @@ func (p *DefaultProjectCommandBuilder) buildProjectPlanCommand(ctx *command.Cont | |||
| foundDir := false | |||
|
|
|||
| for _, f := range modifiedFiles { | |||
| if filepath.Dir(f) == cmd.RepoRelDir { | |||
| // Check if the file is in the directory or any subdirectory of the target | |||
| if strings.HasPrefix(filepath.Dir(f), cmd.RepoRelDir) { | |||
There was a problem hiding this comment.
Personally I would hide this behind a flag to make sure people that want to be very strict can still do so.
There was a problem hiding this comment.
so should we bind this logic to another parameter like --restrict-file-list-recursive ?
There was a problem hiding this comment.
@ibalat, yeah, that looks like a good flag to me. Just be aware that I can review this, but I'm not sure I'm the best person to give a final word if this should be accepted.
There was a problem hiding this comment.
I totally agree with @Fabianoshz. Introducing that flag could help to backwards compatibility 👍
There was a problem hiding this comment.
okey, thanks for your comments. I'll update the pr
|
Thanks for this @ibalat. Can you also look at adding some unit tests for your new functionality. |
This change enhances the file change detection logic in Atlantis to support recursive directory checks for --restrict-file-list parameter. Previously, only direct changes to specified directories were considered for plan and apply. With this update, changes in subdirectories are also detected, ensuring resources that depend on configuration files in nested directories are properly applied.
What:
Why:
In cases where Terraform resources in a directory (e.g., clusters/dev) depend on configuration files from subdirectories (e.g., clusters/dev/configs/dashboards/application), changes to those subdirectories were not triggering the necessary plan and apply commands. This fix resolves that issue, improving the workflow when working with nested configurations.
references
ISSUE #4971