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

Automate re-run/abort permission based on OWNERS file #307

Open
smg247 opened this issue Oct 22, 2024 · 3 comments
Open

Automate re-run/abort permission based on OWNERS file #307

smg247 opened this issue Oct 22, 2024 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@smg247
Copy link
Contributor

smg247 commented Oct 22, 2024

It is currently possible to configure permissions for users and teams to re-run or abort jobs based on the DefaultReRunAuthConfigs defined in the main prow config. This configuration is not sharded, so it cannot be split into the sharded repos' configurations. It also requires manual update to keep in sync with repo owners.

I propose that there be a new boolean field to dictate that users found in OWNERS files (possibly just approvers) be automatically, implicitly populated in the config for the respective repo. This would allow for re-run and abort privileges for all owners of the individual repo, and reduce support burden on the prow maintaining team(s).

@smg247
Copy link
Contributor Author

smg247 commented Oct 22, 2024

/kind feature

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 22, 2024
@petr-muller
Copy link
Contributor

I propose that there be a new boolean field to dictate that users found in OWNERS files (possibly just approvers) be automatically, implicitly populated in the config for the respective repo

  • We'd still need the config to be sharded, right? So that individual repos could opt-in.
  • I'd like to avoid adding booleans for the same reason kube API conventions discourages them - the ideas tend to evolve. Even for OWNERS there are immediately two options I see people ask for (or four, if you consider none and all): approvers and reviewers

But yeah, I think this is useful 👍

@smg247
Copy link
Contributor Author

smg247 commented Oct 25, 2024

We'd still need the config to be sharded, right? So that individual repos could opt-in.

yes, sharding the config is definitely required here.

I'd like to avoid adding booleans for the same reason kube API conventions discourages them - the ideas tend to evolve. Even for OWNERS there are immediately two options I see people ask for (or four, if you consider none and all): approvers and reviewers

Very good point, the configuration will require some more thought

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants