feat: customize atlantis.yaml file name in server side config

[krrrr38]

what

• Server-side config repos.yaml can accept repo_config_file configuration for customizing atlantis.yaml

why

Currently atlantis.yaml file must be put on the repository root. We can use this feature in the following situations.

• service wide mono-repo
  • mono-repo put service specific directory on the repository root like frontend, backend and infrastructure
  • In this case, we want to put atlantis.yaml into infrastructure/terraform/atlantis.yaml, not repository root.
• multiple atlantis servers can handle a same repository.
  • Allow custom name for atlantis.yaml #1273
  • Each atlantis processes have repos.yaml files that have different config_repo_file.

Workaround

• connect multiple atlantis server with Single repo #1345 (comment)
  • But if we use pre_workflow_hook, ATLANTIS_SKIP_CLONE_NO_CHANGES=true does not works. Because ATLANTIS_SKIP_CLONE_NO_CHANGES still needs repository root atlantis.yaml file.

references

• debug PR Customize repo_config_file in server side config file krrrr38/atlantis-debug#6 (comment)
• closes Allow custom name for atlantis.yaml #1273
• relates to Atlantis nodes in different accounts with one repository #249

[nitrocode]

Nice addition! Let me ping the other @runatlantis/maintainers to get a review.

I've reviewed this and the changes seem straight forward.

[jamengual]

hahahah 2 years ago I implemented this same feature ( not as good as this PR) I'm glad to see it coming so complete @krrrr38 thanks for the work.

I have a question:

how is this possible? Each atlantis processes have repos.yaml files that have different config_repo_file.? is that because you could match each repo regex id: to a different repo but if that the case will not be per process, no?

[krrrr38]

@jamengual

how is this possible? Each atlantis processes have repos.yaml files that have different config_repo_file.? is that because you could match each repo regex id: to a different repo but if that the case will not be per process, no?

Like followings.

• repository configurations
  • put atlantis-staging.yaml and atlantis-production.yaml
• server configurations
  • atlantis-staging server run with ATLANTIS_REPO_CONFIG_JSON='{"repos":[{"id":"/.*/", "repo_config_file": "atlantis-staging.yaml"]}]}'
  • atlantis-production server run with ATLANTIS_REPO_CONFIG_JSON='{"repos":[{"id":"/.*/", "repo_config_file": "atlantis-production.yaml"]}]}'
• then setup 2 webhook in the repository, which sent both atlantis-staging server and atlantis-production server
  • Each event processed by both servers.
  • atlantis-staging server handle atlantis-staging.yaml and atlantis-production server handle atlantis-production.yaml.

atlantis-staging.yaml example

version: 3
projects:
- name: project
  branch: /staging/
  dir: infrastructure/staging

atlantis-production.yaml example

version: 3
projects:
- name: project
  branch: /production/
  dir: infrastructure/production

---

Actually, the above case can be handled by one atlantis server with following config 😬 . But we can separate them into multiple atlantis servers for reasons such as the server's IAM.

version: 3
projects:
- name: project1
  branch: /staging/
  dir: infrastructure/staging
- name: project2
  branch: /production/
  dir: infrastructure/production

[krrrr38]

Ah, but in this case with base branch staging, when I comment atlantis plan, atlantis-staging server returns plan result and atlantis-production server returns no projects result. so might be better to set ATLANTIS_SILENCE_NO_PROJECTS=true, too. https://www.runatlantis.io/docs/server-configuration.html#silence-no-projects

[jamengual]

Undestood, I was doing something similar before. you might want this too:

https://www.runatlantis.io/docs/server-configuration.html#vcs-status-name

and a well documented example in docs will be wonderful.

[jamengual]

Another way this could be done ( not in this PR) is using a github action that can route the call to the specified atlantis server without having to have two webhooks in the same project.

if the atlantis command could be configured to pass a name like ATLANTIS_COMMAND_NAME="atlantis-prod" or some other method could work too ( label based etc)

this is me just thinking out loud and I like your aproach more because it supports all the VCSs

[GenPage]

Great PR, it would be nice to see some ways to auto-trigger "silence-no-projects" if a custom Atlantis YAML is set but it is not trivial. I generally would like us to try and reduce the number of flags we have but outside the scope of this PR :)

[krrrr38]

Thank you for the reviews, everyone.

a well documented example in docs will be wonderful.

I added the usecase like c55a253. I'm not good at English, so let me know if something is weird.

call to the specified atlantis server

I've seen such an issue #326. Sounds good.

[krrrr38]

I didn't know this usage, but we can call one of atlantis-server by using vcs user. (BTW run apply is dangerous and useless...?)

atlantis/server/events/comment_parser.go

Lines 98 to 109 in 585ce1e

	// Valid commands contain:
	// - The initial "executable" name, 'run' or 'atlantis' or '@GithubUser'
	// where GithubUser is the API user Atlantis is running as.
	// - Then a command: 'plan', 'apply', 'unlock', 'version, 'approve_policies',
	// or 'help'.
	// - Then optional flags, then an optional separator '--' followed by optional
	// extra flags to be appended to the terraform plan/apply command.
	//
	// Examples:
	// - atlantis help
	// - run apply
	// - @GithubUser plan -w staging

[GenPage]

That is a nice call out, and something I learned today. @krrrr38 Are you asking a question about run apply or pointing out that its dangerous and useless? I think it should be removed, but we don't know any other use cases by users. It seems to just be an alias for atlantis.

atlantis/server/events/comment_parser.go

Lines 147 to 150 in 585ce1e

	executableNames := []string{"run", atlantisExecutable, "@" + vcsUser}
	if !e.stringInSlice(args[0], executableNames) {
	return CommentParseResult{Ignore: true}
	}

[krrrr38]

@GenPage

I discuss it in the other PR, too. I'm worry about that almost users don't know it and it might execute unintentional apply.

But currently this feature is already provided and we might be better to discuss it in the next major release and so on, not in this PR.

[nitrocode]

Thank you again @krrrr38 ! These contributions are very helpful!

[krrrr38]

Thank you for your high quality and quickly review, too.