Ability to run terraform plan outside pull request cycle (drift detection)

[lkysow]

Via @lorenzoaiello, Atlantis should be able to run terraform plan on demand or on a schedule in order to identify whether the actual resources have drifted from what's defined in Terraform.

[johnlinvc]

I'm also interested in this feature. Which is essential to reach a GitOps1 like model for terraform.
I want to contribute this feature if possible.
The current design I have in mind is:
Run atlantis plan in master branch on all defined workspaces in atlantis.yml (or root dir) on a schedule. If there's diff output for more than N consecutive atlantis plan, create a GitHub issue to alert the user.

1. Add parameter drift-golden-branch in atlantis.yml which represent the branch terraform plan will run against. Defaults to master.
2. Add parameter drift-detection-interval in atlantis.yml, defaults to 1 day.
3. Add parameter drift-warning-threshold in atlantis.yml, defaults to 3 times.
4. Add parameter drift-detection in atlantis.yml, defaults to false.

The one thing I'm not sure is that if this should be turned on by default. or should we provide a switch for the feature when starting Atlantis.

[majormoses]

Some thoughts:

• should not be on by default, operator should opt in
• these would need to be serverside options (be it config or CLI) to avoid abuse. see Restrict Plan or Apply to Github Teams or Github Users #308 for some extra context
• you would probably need to specify a mapping for each repo as not all teams manage their projects the same way
• would the action be configurable? who would be assigned to the issue? For example at my org we use an internal system for stories, bugs, etc and no one would actually look at a github issue.

[smiller171]

@majormoses I think configuring an outgoing webhook would allow most use-cases for the notification.

[lkysow]

I think this is out of the scope of Atlantis unfortunately. Atlantis is best focused on Terraform pull request workflows. It would be a lot of work to build this which would take time away from that focus and make other features around pull request workflows more complicated.