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

Ability to disable bulk approval, possibly all bulk actions for a particular repository #550

Open
lesv opened this issue Oct 18, 2021 · 3 comments
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@lesv
Copy link

lesv commented Oct 18, 2021

@kolea2, @Neenu1995 and I were having a chat regarding some bulk PR's and realized that the Bigtable team would like to manually review most PR's.

So, that means that we have to think when using the repo CLI tool, which is never a good thing. It would be nice if we could edit a configuration file in the repository and have the ability to disable some or all operations, particularly approve on the repo.

@lesv lesv added priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. labels Oct 18, 2021
@JustinBeckwith
Copy link
Contributor

Followed up a little over email - but wanted to share here that this is technically possible today :) Two approaches I can think of:

To prevent the PRs from ever going out, the person authoring the PR could use a query in repo.yaml that specifically blocks out as subset of repositories:

repoSearch:  'org:googleapis language:java NOT "googleapis/google-cloud-java"'

You could also play with things like repository topics to achieve the same effect:

repoSearch: "org:googleapis language:java -topic:artisanal"

Another approach here would be to modify your CODEOWNERS to remove yoshi-java. This would have the side effect of making you and your team entirely responsible for all reviews, which may honestly be the best route here. I would advocate for this over the first approach, since that sounds like what you're really after.

I want to discuss this internally to learn more about your specific scenarios, just to make sure what we're doing is working broadly for all languages.

@bcoe bcoe removed the priority: p1 Important issue which blocks shipping the next release. Will be fixed prior to next release. label May 9, 2022
@bcoe
Copy link
Contributor

bcoe commented May 9, 2022

@Neenu1995 do you know if this is still a need that the Java team has, I know you've been moving towards using a sheet for managing bulk operations.

@Neenu1995
Copy link

The sheet makes this possible and the repo tool is rarely used anymore by the java team. I would say it is not a requirement right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

4 participants