Enable release-note automation on kubernetes-csi

[jsafrane]

All repos under kubernetes-csi should have release-note plugin enabled and require PRs to have ```release-note.

We want to use the same release-notes script as kubernetes/kubernetes to automate CHANGELOG creation. Most repos under kubernetes-csi already have appropriate PR template.

cc @msau42 @saad-ali @childsb from sig-storage side.

[msau42]

0 files changed?

[jsafrane]

Fixed :-)

[msau42]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 594e1ba62457e6e6f182d09f71a881c20e61bfd9

[msau42]

/assign @cjwagner

[cjwagner]

This will affect a lot of repos. Could you please link to the slack or email thread where you got approval/consensus for this change?
/cc @cblecker @spiffxp

[spiffxp]

/hold
Agree with @cjwagner. It would really help to see a written decision here with approval of the kubernetes-csi subproject owners. As the kubernetes-csi subproject currently lacks contact details like slack channel, mailing list, etc. I looked in #sig-storage, kuberentes-sig-storage@ and couldn't find anything.

Going off of https://github.com/kubernetes/community/blob/master/sig-testing/charter.md#deploying-changes, this impacts only a single subproject and a single SIG, but because there are so many repos involved it would be a pain to roll back the sundry do-not-merge/release-note-label-needed labels if it turns out this wasn't intended.

[spiffxp]

... I didn't really finish my charter thought. I know our charter doesn't state that there's a need for a written decision specifically, but:

• the change to me is more than "low risk" because it touches so many repos and is not easy to roll back, so a little more formality is warranted
• it's less than "medium risk" because it only involves a single sig, so I don't think sig contribex needs to review nor does kuberentes-dev@ need to be notified

ergo, asking for a written / documented decision

[cblecker]

I think the decision is up to the sig (storage in this case), but because of the number of repos impacted, I'd ask if we could have a notification cc'd to k-dev as an FYI.

[jsafrane]

There is kubernetes-csi/docs#142. I am not sure it was discussed on any WG-CSI meeting, just on slack. I put it on Friday's agenda to get formal agreement of the proposal.

[saad-ali]

@msau42 and I spoke with @spiffxp offline. We agree that kubernetes-CSI should be renamed from "workgroup" to "subproject". And we'll work to do that.

In terms of this change, I approve on behalf of SIG-storage. This will require a release note for each new PR in the kubernetes-csi org.

/lgtm
/approve

[cjwagner]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cjwagner, jsafrane, saad-ali

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 [cjwagner]

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

[cblecker]

@saad-ali As I noted above, would you mind sending a note to k-dev as an FYI of the change before pulling the hold here? Thank you!

[saad-ali]

@cblecker sure thing. Here is the SIG-storage thread. I CC'd kubernetes-dev on that thread here.

/hold cancel

[k8s-ci-robot]

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

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

In response to this:

All repos under kubernetes-csi should have release-note plugin enabled and require PRs to have ```release-note.

We want to use the same release-notes script as kubernetes/kubernetes to automate CHANGELOG creation. Most repos under kubernetes-csi already have appropriate PR template.

cc @msau42 @saad-ali @childsb from sig-storage side.

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.