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.

• I'd be willing to implement this feature (contributing guide)

Describe the user story
As we move towards #2496, one thing that has come up was more formal approach to the levels of support for various features. More specifically, the question came up how do we understand features that are only supported in some but not all of our VCSs.

Looking at https://www.runatlantis.io/docs/server-configuration.html, per-VCS settings falls into two categories:

1. Configuring that VCS (i.e. --gh-hostname or --azuredevops-user)
2. Enabling/using per-VCS features

Features that potentially fall into category 2 are:

• https://www.runatlantis.io/docs/server-configuration.html#gh-allow-mergeable-bypass-apply
• https://www.runatlantis.io/docs/server-configuration.html#gh-team-allowlist
• https://www.runatlantis.io/docs/server-configuration.html#gitea-page-size
• https://www.runatlantis.io/docs/server-configuration.html#gitlab-group-allowlist

The difficulty with having VCS specific flags is it doesn't give us a path for implementing this feature on other VCSs, and more broadly doesn't explain whether this is a general feature that happens to be implemented once, or truly a per-VCS setting.

I see a few possible options here (which might be different for each of the flags above)

1. Classify the flag as simply a "configuration" for that VCS
2. Introduce a new flag without the VCS-specific logic, have it be unimplemented for the other VCSs, deprecate the existing flag
3. Allow for per-VCS feature flags

Describe the solution you'd like

I think we should reserve --<vcs>-* flags for configuration of that VCS only. If there is a feature that could theoretically exist for other VCSs but isn't implemented at this point, it should be called out as such (maybe with a WARNING in the code if you specify one of these flags but are running a VCS that doesn't support it?)

Describe the drawbacks of your solution

This requires some work, both in the short term to clean up what we have now, as long as complicating the addition of new features that are only being implemented for one VCS (depending on the exact implementation of this, maybe it's just a tweak in how it's documented).

Describe alternatives you've considered

We could leave things as they are. I'm actually surprised how few of these flags there turned out to be; Atlantis works very hard to make everything work on all VCSs, one way or another. So maybe these oddities can simply be exceptions to the rule? Or maybe we should call them out explicitly?