sig-release: Blockade changes to critical k/release tooling

[justaugustus]

ref: kubernetes/release#816
Signed-off-by: Stephen Augustus saugustus@vmware.com

[justaugustus]

/hold
(I think I have a few more patterns to add)

[justaugustus]

Done.
/hold cancel

[justaugustus]

/assign @cblecker @fejta
/cc @kubernetes/sig-release-admins @kubernetes/release-engineering @nikhita

[cblecker]

/hold

Why wouldn't we just do this with OWNERS files?

[justaugustus]

@cblecker -- This is essentially saying I want explicit approval from a repo admin (SIG Release Chair) before changing one of these tools. We have top-level approvers in k/release that I still want to be able to approve other changes without impact.

As the tools are scattered across the repo, I need an extra gate to protect them and I heard that required_reviewers doesn't actually get respected?
Some of this could probably be obviated if all of the tools were in a single (or a few) subdirectories with no_parent_owners: true, but at this moment, I don't have a clear picture of what could break if I move things around.

[alvaroaleman]

/uncc

[cjwagner]

Sounds like using blockade is most appropriate here, but just as an FYI Tide support blocking merge to entire branches or repos using a merge blocking issue: https://github.com/kubernetes/test-infra/blob/master/prow/cmd/tide/config.md#merge-blocker-issues

test-infra/prow/config.yaml

Line 458 in 152915a

blocker_label: tide/merge-blocker

[justaugustus]

@cjwagner -- Whoa, that's cool. Thanks for the tip! Agreed that blockade might still be the right path here.

[fejta]

/unassign
/assign @cjwagner

No concerns with the general intent

[cblecker]

I started writing something up and then apparently closed the tab 🤦‍♂ .

Basically, I still feel like this is an anti-pattern (blockading files, and then manually removing the label each time you need to change them). It provides a different contributing structure than normal, and requires manual intervention.

I could be convinced to be okay with this for a limited period of time to help stabilize the situation (30d?). Ultimately though, reorganizing files (either move the scripts all together, or move the other stuff all together) and then using OWNERS files should be the goal.

[justaugustus]

@cblecker -- yep, the intent for the blockade is definitely temporary!
I want to rearrange the tools but I don't feel comfortable doing so until we can identify where they're used and have jobs to protect changes to them. Much of that work is already in flight. :)

[cblecker]

What's a reasonable time frame for this work?

[justaugustus]

Spoke to @cblecker on Slack.
Setting a deadline for 8/8/19 and added a comment to remove the blockade afterwards.

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: c47a292f5d6f4bab026f0f7c6713822a3d3660a0

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cblecker, justaugustus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• prow/OWNERS [cblecker]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[justaugustus]

Thanks again, Christoph!
/hold cancel

[k8s-ci-robot]

@justaugustus: Updated the plugins configmap in namespace default using the following files:

• key plugins.yaml using file prow/plugins.yaml

In response to this:

ref: kubernetes/release#816
Signed-off-by: Stephen Augustus saugustus@vmware.com

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

why not .*? :P