Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoplan modules functionality not working with per-repo config #3122

Closed
bobziuchkovski opened this issue Feb 11, 2023 · 8 comments · Fixed by #3272
Closed

Autoplan modules functionality not working with per-repo config #3122

bobziuchkovski opened this issue Feb 11, 2023 · 8 comments · Fixed by #3272
Labels
bug Something isn't working

Comments

@bobziuchkovski
Copy link

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.

Overview of the Issue

We're running Atlantis v0.22.3 with:

  • ATLANTIS_AUTOPLAN_MODULES=true
  • Per-repo atlantis.yml config generated as part of a custom pre_workflow_hooks command
  • Local modules in our git repo

Unfortunately, when we make changes to any of the local modules, the projects in repo atlantis.yml that are dependent on those modules don't register as updated/autoplanned.

We traced the code that invokes FindModuleProjects in server/events/project_command_builder.go and it looks like this is part of a conditional that is only executed when per-repo config is not present. We couldn't find any other calls to the dependent module resolution.

Is this expected, or is there a way to enable the dependent module auto-planning for per-repo config projects/stacks?

Reproduction Steps

  1. Use a project structure like the following (simplified):
terraform/app
├── README.md
├── main.tf
├── modules.tf
terraform/modules/ecs
├── ecs.tf
  1. Add a repo-level atlantis.yml file that defines terraform/app as a project, where terraform/app depends on ../modules/ecs as a module.
  2. Commit changes to terraform/modules/ecs/ecs.tf
  3. Observe no autoplan

Environment details

Repo atlantis.yaml file:

version: 3
projects:
- name: app
  dir: terraform/app
  workspace: prod

Additional Context

We're using the per-repo atlantis.yml config in order to skip planning for the default workspace when other workspaces exist. In cases where only the default workspace exists, we use it.

We'd love to avoid using the per-repo config if it'd be possible to replicate that behavior without it. Particularly if it means missing-out on functionality like module autoplanning.

@bobziuchkovski bobziuchkovski added the bug Something isn't working label Feb 11, 2023
@wyardley
Copy link
Contributor

Thanks for creating this issue - this mirrors / confirms what we're seeing as well -- we've been tearing our hair out to figure out why it didn't work.

note: we also explicitly set autoplan to false per directory / project in our config, though my read is that shouldn't be an issue, and we've tested removing that bit anyway for debugging

@nitrocode
Copy link
Member

cc: @iamnoah

related PR #2507

@iamnoah
Copy link
Contributor

iamnoah commented Feb 23, 2023

FWIW, the only reason this isn't supported is because I didn't have a per-repo atlantis.yml setup to dev and test on. I don't know of any reason it shouldn't be possible.

@nitrocode
Copy link
Member

nitrocode commented Feb 25, 2023

Ah that makes sense. For now, I suppose we'll have to document the limitation.

If anyone feels like contributing this change, it could be as simple as duplicating this block or encapsulating this block into a function and executing the call in both the "if" and "else" conditions (or before the if/else block). It will probably require changes to DetermineProjectsViaConfig and DetermineProjects functions.

This block

// build a module index for projects that are explicitly included
moduleInfo, err := FindModuleProjects(repoDir, p.AutoDetectModuleFiles)
if err != nil {
ctx.Log.Warn("error(s) loading project module dependencies: %s", err)
}
ctx.Log.Debug("moduleInfo for %s (matching %q) = %v", repoDir, p.AutoDetectModuleFiles, moduleInfo)
modifiedProjects := p.ProjectFinder.DetermineProjects(ctx.Log, modifiedFiles, ctx.Pull.BaseRepo.FullName, repoDir, p.AutoplanFileList, moduleInfo)

Is in the else block of this if statement

if len(repoCfg.Projects) > 0 {
matchingProjects, err := p.ProjectFinder.DetermineProjectsViaConfig(ctx.Log, modifiedFiles, repoCfg, repoDir)
if err != nil {
return nil, err
}
ctx.Log.Info("%d projects are to be planned based on their when_modified config", len(matchingProjects))
for _, mp := range matchingProjects {
ctx.Log.Debug("determining config for project at dir: %q workspace: %q", mp.Dir, mp.Workspace)
mergedCfg := p.GlobalCfg.MergeProjectCfg(ctx.Log, ctx.Pull.BaseRepo.ID(), mp, repoCfg)
projCtxs = append(projCtxs,
p.ProjectCommandContextBuilder.BuildProjectContext(
ctx,
cmdName,
subCmdName,
mergedCfg,
commentFlags,
repoDir,
repoCfg.Automerge,
repoCfg.ParallelApply,
repoCfg.ParallelPlan,
verbose,
p.TerraformExecutor,
)...)
}
} else {

so if there are more than zero projects defined, the --autoplan-modules flag logic will not execute.

@md-magenta
Copy link

Since this is closed, shouldn't we revert the doc changes from #3166?

@jamengual
Copy link
Contributor

@nitrocode

@nitrocode
Copy link
Member

I'm running into this issue again in version 0.26.0 #3897

@glasser
Copy link
Contributor

glasser commented Nov 3, 2023

I've also noticed that autoplan-modules doesn't work when skip-clone-no-changes is set (it can decide there's no changes because it doesn't take the modules stuff into account).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants