Improve Autoplanning Behavior for Project Subdirectories

[cbfield]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story
My company runs a monorepo with Terraform configurations for many teams. We are currently using Atlantis v0.22.2

We recently started using the --autoplan-modules flag in order to avoid the need to maintain a gigantic (7k+ lines) list of projects and their when_modified modules in atlantis.yaml. We have also removed the projects configuration from atlantis.yaml per the docs pointing out this issue: #3122

We have --autoplan-file-list set to */**,!.circleci,!.github.

The behavior we expect from this is that changes to any files within a project directory or any of its subdirectories trigger autoplans for that project. The behavior we have observed is that only changes within the project directory itself, not subdirectories, will trigger plans for that project.

So suppose we have a project that looks like this:

root/
  project1/
    templatefiles/
      something.tpl
    main.tf

Where I reference something.tpl using the templatefile() function from somewhere in main.tf. If I open a PR that only changes the content of something.tpl, I would like to see an autoplan started in project1.

We have many similar cases across the monorepo, and I don't want to tell all of our teams "Don't organize your files; keep them all at the root of your project instead so it autoplans nicely".

I also don't want to go back to the pain of managing a gigantic atlantis.yaml file that gets tons of merge conflicts.

Describe the solution you'd like
It looks like projects are selected for autoplans based on files changed according to this function:

• atlantis/server/events/project_finder.go

  Line 301 in 20401e1

  func getProjectDirFromFs(files fs.FS, modifiedFilePath string) string {

Right now, it simply returns the directory containing the file that was changed (root/project1/templatefiles/ in the example described above), unless the directory containing the changed file is named env or the path to the file includes /modules/.

I would suggest that this function do this instead:

1. If the directory containing the changed file (root/project1/templatefiles/) contains any .tf files and is not a module directory (path contains /modules/), return that directory.
2. Else, move to the parent directory (root/project1/). If there are any .tf files there and it is not a module directory (path contains /modules/), return that directory
3. Repeat 2 until you return a directory or reach the root of the repo. If you reach the root of the repo and see no .tf files, return the directory containing the changed file (root/project1/templatefiles/) as long as it is not a module. If it is a module, return an empty string.

This gives teams the freedom to organize their non-tf files within subdirectories of a project without compromising autoplanning behavior or requiring them to maintain projects entries in atlantis.yaml.

This also includes the behaviors currently exhibited by the getProjectDirFromFs function:

1. If files are in an env directory and the parent directory has a main.tf file, return the parent directory.
2. If files are in a directory whose path contains /modules/, and if the parent to that directory contains main.tf, return the parent directory.

Describe the drawbacks of your solution
Perhaps some groups keep .tf files in the root of their monorepo but do not intend to treat them like a project that should be planned. Then if someone makes a change within a .github or .circleci (or something like that) directory and the changes are matched by --autoplan-file-list, they will see a plan they didn't expect.

Describe alternatives you've considered
If there are concerns about unintended plans being run because of the implementation suggested above, then it could be gatekept behind a boolean flag like --autoplan-subdirs.

Or, instead of making an exception just for env directories, we can define a list of directories that trigger plans in their parent directories with a flag like --autoplan-subdir-list.