Feature Request: Autoplan based on pull request destination branch

[Phylu]

We currently use a gitflow approach for all our repositories including the terraform repository. We have different environments of our infrastructure which are based on different terraform/atlantis projects.

I suggest to have a configuration to run autoplanning based on the destination branch of a pull request. For example:

• If a pull request is opened against the branch "development", the terraform/atlantis project "development" should be run. i.e. atlantis plan -p development
• If a pull request is opened against the branch "master", the terraform/atlantis project "master" should be run. i.e. atlantis plan -p development

Therefore I suggest the autoplan config to be extended to contain the following features:

enabled: true
when_modified: ["*.tf"]
destination_branch: branchname

• Key: destination_branch
• Type: string
• Default: no
• Required: no
• Description: If destination of the pull request is the configured branch, the project will be planned

Where I am not sure is how when_modified and destination_plan should interact.

• Are they allowed to be configured both?
• Which one takes precedence? E.g. if both are defined must any of them match or both for a project to be autoplanned.

If this feature seems interesting and the behaviour is clear, I might take a shot at implementing this.

[lkysow]

Hi Janosch, On first glance this seems reasonable. I do want to think more about what other conditions users might have for autoplanning. If there's a lot of them, then adding a new key for each is not a good idea and instead I would prefer a plugin-type solution.

Are they allowed to be configured both?

Yes, they're both necessary.

Which one takes precedence? E.g. if both are defined must any of them match or both for a project to be autoplanned.

They must both match. But if destination_branch is not set, it defaults to matching any.

[Phylu]

I do want to think more about what other conditions users might have for autoplanning. If there's a lot of them, then adding a new key for each is not a good idea and instead I would prefer a plugin-type solution.

Sure. Let me know what makes most sense here.

[smiller171]

I'm looking to be able to select the workspace to plan and apply against based on the base branch. It looks like this suggestion would allow me to do that.

[lkysow]

I'm looking to be able to select the workspace to plan and apply against based on the base branch. It looks like this suggestion would allow me to do that.

You could do this through custom workflows. You already have the HEAD_BRANCH_NAME and BASE_BRANCH_NAME variables available.

[smiller171]

~@ivankisic~ @lkysow yes, and I plan to work something like that out. Unfortunately it's made more difficult because the branch names don't match the workspace names (and that's not likely to change) So I have to create a mapping between the branch name and the workspace name.

It's unclear where variables can be expanded right now.

[ivankisic]

@smiller171 not sure why I'm being tagged here. If you're aiming for @lkysow that's with an "L".

[smiller171]

@ivankisic Yep. Not sure how I managed that, sorry

[phzietsman]

You could do this through custom workflows. You already have the HEAD_BRANCH_NAME and BASE_BRANCH_NAME variables available.

@lkysow If I wanted to limit plans to only PRs against develop and master, how would I achieve this? I can see how the BASE_BRANCH_NAME can be used to inject the var-file to apply, but how do I prevent plans for all other PRs?

In the server side repo config example there is a branch option, but in the references its not there and I get an error if I pass it into the config. I'm sure I'm missing something simple.