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

Allow for planning different sets of projects in a PR, regardless of branch attributes in the repo-level config #4263

Closed
1 task
dimisjim opened this issue Feb 19, 2024 · 3 comments
Labels
feature New functionality/enhancement wont-do Unfortunately due to scope or project direction we won't build this in a reasonable amount of time

Comments

@dimisjim
Copy link
Contributor

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.

Describe the user story

I'd like to have what is mentioned here: #254 (comment)

Basically some sort of a flag that allows the following workflow:

  • autoplan happens according to the branch filter in the repo-level yaml
  • if the user chooses, be able to plan for another "branch"-based project via a comment command, using the -p flag

Describe the solution you'd like

some sort of a server config flag

Describe the drawbacks of your solution

Describe alternatives you've considered

@dimisjim dimisjim added the feature New functionality/enhancement label Feb 19, 2024
@jamengual
Copy link
Contributor

This is not recommended because now you are allowing users to bypass the rules added by admins of the repo and go about planning another project outside of the scope of the PR. If you need to plan another project then create another PR.

@jamengual jamengual added the wont-do Unfortunately due to scope or project direction we won't build this in a reasonable amount of time label Feb 19, 2024
@dimisjim
Copy link
Contributor Author

dimisjim commented Feb 20, 2024

In our case, the atlantis.yaml file is modified on a per-repo basis (because of this limitation / way of repo matchers work on the server-side config currently: #4245), so it's not really about "overriding rules added by admins". Also, in our case, planning for multiple projects is within the scope of the PR (even if the PR is about merging into a particular env branch), coz we would like to run a plan if more than one projects are affected. For example, we have a setup in which a change in dev, could potentially affect qa (assuming that both configs use the same main.tf and the change is there). Do you think it's still not recommended based on this?

EDIT: I've gone around this, using the when_modified option, and completely abandoned the branch one.

EDIT 2: Including a custom run step for apply in my custom project workflow, I've achieved the functionality that I wanted:

qa:
    plan:
      ...
    apply:
      steps:
      - run: |
          if [ "$BASE_BRANCH_NAME" = "qa" ]; then
            echo "we are on qa branch, thus proceeding with the apply!"
            terraform${ATLANTIS_TERRAFORM_VERSION} apply "$PLANFILE"
          else
            echo "we are not on qa branch, thus canceling the apply"
          fi

Thus closing this issue 👍

@dimisjim dimisjim closed this as not planned Won't fix, can't repro, duplicate, stale Feb 20, 2024
@jamengual
Copy link
Contributor

when_modify is a good use for this.
I will say that you should do a Dev change and then create a PR for QA apply , prod etc, but this is a "how do we work as a company in our VCS problem" not much of how atlantis does things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement wont-do Unfortunately due to scope or project direction we won't build this in a reasonable amount of time
Projects
None yet
Development

No branches or pull requests

2 participants