More power for authorized users in self-service community operators

[2uasimojo]

Self-service community operator version PRs are way cool!

However, a handful of things I've noticed that would make it even cooler:

• When adding an authorized user to ci.yaml (e.g. 1, 2), a repo admin still needs to participate to get the PR merged. It would be cool if pre-existing reviewers in ci.yaml could have that power (via /lgtm or /approve or whatever).
• When a test fails, even an authorized (via ci.yaml) user can't seem to retest or add ok-to-test.

[mvalarh]

* When adding an authorized user to ci.yaml (e.g. [1](https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/63), [2](https://github.com/k8s-operatorhub/community-operators/pull/65)), a repo admin still needs to participate to get the PR merged. It would be cool if pre-existing reviewers in ci.yaml could have that power (via `/lgtm` or `/approve` or whatever).

We were already allowing it, but it is not working. The problem is that when user (authorized user) would do the comment (via /lgtm or /approve or whatever) then workflow comment handler is executed with that user's permissions and if that user (authorized user) doesn't have write access to repo (by default no one has) then label cannot be set by that user. Only repo admin can. I am still thinking about this feature (not high priority). But you can give me hint if you have some proposal.

[mvalarh]

* When a test fails, even an authorized (via ci.yaml) user can't seem to [retest](https://github.com/k8s-operatorhub/community-operators/pull/75#issuecomment-891143786) or [add ok-to-test](https://github.com/k8s-operatorhub/community-operators/pull/75#issuecomment-891148861).

To retest one can do:

• convert issue to draft
• click on "Ready for review"

[mvalarh]

Feel free to reopen

[mvalarh]

@2uasimojo I just implemented feature with authorized_label when PR is approved by reviewer. Let me know when you will have such PR so we can test it. Thanks

[mvalarh]

Possible workflows

1. approve
2. /hold
3. /unhold

or

1. approve
2. author will push something

or

1. approve
2. make draft Issue
3. Ready for review

Note: We always rely on information that of last github reviewer and it hase to be in state APPROVED

[2uasimojo]

Thanks for working on this @mvalarh!

Perhaps next Monday (when we do our regular push) we can contrive a scenario to test this. Let me know if this would work:

1. Prepare: merge a PR removing a user from ci.yaml. It will be @abutcher's turn on rotation next week, so if he agrees, we can experiment on him :P
2. Andrew submits the week's PR as usual. Since he's no longer in ci.yaml, it won't be approved.
3. Have someone who's still in ci.yaml (e.g. me) approve the PR
4. ...and IIUC at this point we have to nudge the PR somehow? Either hold->unhold, draft->ready, or Andrew pushes an update?
5. Clean up: Restore Andrew to ci.yaml.

Will that be an effective test?

[2uasimojo]

We tested this via #324 (to remove abutcher from reviewers) and #326 (which he submitted and I approved). It works! Thanks @mvalarh!

We're going to test a different flow -- say the draft/ready one? -- by having Andrew submit the PR to restore himself to ci.yaml.

[2uasimojo]

It seems like when the submitter is not a reviewer, the bot puts a /hold on the PR anyway. So the hold-unhold flow is kind of kicked off by default.

[mvalarh]

Bot is putting in hold only in case ci.yaml is changed

[2uasimojo]

@mvalarh I'm happy with the functionality as we tested it. If you'd like us to test some other permutation, let us know. Otherwise I'm happy to close this issue.

[mvalarh]

Documentation is located : https://k8s-operatorhub.github.io/community-operators/self-merge-updates/#how-do-i-approve-pr