Ignore Repos where atlantis.yaml doesn't exist or projects is an empty list

[ConvoyTom]

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 an Atlantis developer, I would like the ability to have Atlantis ignore repositories within my GitHub organization that do not have an atlantis.yaml defined OR have an atlantis.yaml file with no projects defined. We defined our web hooks on the organization level and have atlantis enabled for all repositories. Maintaining the list for only repositories that have an atlantis.yaml file or one with projects defined could become difficult to manage and lead to a negative developer experience.

We also have a non-standard naming convention for our repositories so filtering out libraries or other services that no not need terraform running is a headache.

We have experience situations where Atlantis plan will hang which results in a service not being able to merge. This happens on services that do not have an atlantis.yaml file as we configured Atlantis for all repos per reasons above

Describe the solution you'd like
A server configuration flag such as --skip_atlantis_no_projects. It could default to false to maintain backwards compatibility.

Describe the drawbacks of your solution
This would require Atlantis to clone each repository to scrape it to understand whether it contains an atlantis.yaml file or not.

Describe alternatives you've considered
We could implement the web hooks at the service level. But this leads back to the original user story comment about maintaining that at the infrastructure level could become a headache as services are created weekly that are not exactly in our purview.

[ConvoyTom]

bump

[ConvoyTom]

anyone have any thoughts on this?