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

Feature request: flag to disable plan/apply on projects not included in atlantis.yaml #1876

Closed
grace-hunter opened this issue Nov 1, 2021 · 5 comments · Fixed by #2969
Closed
Labels
feature New functionality/enhancement

Comments

@grace-hunter
Copy link

We have a monorepo and would like to have a separate Atlantis instance per environment (stage, prod, etc).

So far, we've accomplished this by generating a different atlantis.yaml on each Atlantis server via a pre-workflow hook.
The --silence-no-projects and --silence-vcs-status-no-plans flags are set, so only the appropriate Atlantis server responds responds to each request. This works nicely for autoplanning and regular atlantis plan/atlantis apply.

When you run atlantis plan -d <dir>, however, all of the Atlantis instances respond, so you get one correct plan and then several unwanted plans that (in our case) fail. If you subsequently run atlantis apply -d <dir>, you get one correct apply result and several No plan found comments.

If there was an option to only allow plan/apply to run on projects listed in atlantis.yaml and skip everything else, I think that would solve this problem. Alternatively, if anyone else has an existing workaround please let me know!

@spuder
Copy link

spuder commented Nov 3, 2021

We are also running multiple atlantis servers because we are on-prem and have hard network segmentation limits.
We are doing the same thing where we have dynamically generated atlantis.yaml files so only the production atlantis runs production terraform.

atlantis server --repo-config=/local/repos.yaml --silence-no-projects --silence-vcs-status-no-plans

/local/repos.yaml

#!/bin/bash
set -u
ATLANTIS_ENV=$1
cat >atlantis.yaml <<- EOF
version: 3
automerge: false
projects:
- name: consul-${ATLANTIS_ENV}
  dir: consul/${ATLANTIS_ENV}
  workspace: default
  autoplan:
    enabled: true
    when_modified: ["*.tf"]
- name: nomad-${ATLANTIS_ENV}
  dir: nomad/${ATLANTIS_ENV}
  workspace: default
  autoplan:
    enabled: true
    when_modified: ["*.tf"]
EOF
cat atlantis.yaml

However we also find that when doing atlantis plan -p <environment> that the non-acting atlantis server spits out a superfluous error. We haven't found a workaround yet.

Screen Shot 2021-11-03 at 3 56 47 PM

It seems like --silence-no-projects should be hiding these messages. But we have that configured on all atlantis servers with no change in behavior.

--silence-no-projects will tell Atlantis to ignore PRs if none of the modified files are part of a project defined in the atlantis.yaml file.
This is useful when running multiple Atlantis servers against a single repository so you can delegate work to each Atlantis server. Also useful when used with pre_workflow_hooks to dynamically generate an atlantis.yaml file.

https://www.runatlantis.io/docs/server-configuration.html#flags

For reference, here is the MR where --silence-no-projects was added #1469

@jamengual
Copy link
Contributor

is this still happening with v0.19.8?

@jamengual jamengual added waiting-on-response Waiting for a response from the user feature New functionality/enhancement labels Aug 26, 2022
@github-actions github-actions bot added the Stale label Oct 13, 2022
@jstadnik
Copy link

With atlantis v0.20.0 this seems to still be the case.

@github-actions github-actions bot removed the Stale label Oct 14, 2022
@nitrocode nitrocode removed the waiting-on-response Waiting for a response from the user label Nov 19, 2022
@kemv
Copy link

kemv commented Dec 12, 2022

Any updates on this ?

@nitrocode
Copy link
Member

Sounds like we need a contributor who will expand the --silence-no-projects flag to prevent the pr comment mentioned by @spuder . We're always looking for contributors @kemv . Please feel free to propose a pr to resolve this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants