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

Remove old hardcoded list of repo excludes #324

Open
Flipez opened this issue Aug 29, 2021 · 4 comments
Open

Remove old hardcoded list of repo excludes #324

Flipez opened this issue Aug 29, 2021 · 4 comments
Labels
backend/enforcer Updates are performed on Github objects optimization Improve an existing feature

Comments

@Flipez
Copy link
Member

Flipez commented Aug 29, 2021

In the voxpupuli.yml we keep a (short) list of repos we exlcude. Since we now support configuration we should remove that once every repo has implemented the enabled: false flag to the .sync.yml.

List:

@ekohl
Copy link
Member

ekohl commented Aug 29, 2021

I'd like to voice my concern about this. My goal is to get rid of .sync.yml as much as possible. Ideally, all modules follow the same standards.

Have you considered using a repository label in Github? Something like vp-tasks-skip?

@bastelfreak
Copy link
Member

I thought about the repository labels/topics as well. With the .sync.yml we have the advantage of a review/permission management. I just checked https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/classifying-your-repository-with-topics and only admins can currently manage topis, so that might not be too bad.

@Flipez
Copy link
Member Author

Flipez commented Aug 29, 2021

The advantage of a YAML file (whatever it is named) is in my opinion the possibility for different options (eg. disable a specific check, disable comments for a specific check).

Currently we only support three flags but I think this will become more and more as we also might introduce new checks or more comments/actions for different things. Managing them all through topics would be pretty confusing I think as there is no possibility for nesting them.

I not necessarily need the configuration to happen in the .sync.yml but I would like to keep in in the form of a file (maybe a vpt.yml or similiar?

@ekohl
Copy link
Member

ekohl commented Aug 30, 2021

Perhaps #304 (comment) was meant for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend/enforcer Updates are performed on Github objects optimization Improve an existing feature
Projects
None yet
Development

No branches or pull requests

3 participants