Test-infra: milestone-maintainer: allow kind/failing-test as one of the required labels

[spiffxp]

When updating release docs as part of https://github.com/kubernetes/community/issues/1579 we decided that kind/bug was no longer required for ci-signal filed issues. It turns out we were wrong. The milestone-maintainer munger expects one of kind/cleanup, kind/bug or kind/feature

The workaround would be to update docs and say kind/cleanup + kind/failing-test are required failing test issues. This is weird though. Let's just update the munger.

I'd rather the milestone-maintainer munger was no more, but I don't have time to port it over

Example of where this is being encountered: https://github.com/kubernetes/kubernetes/issues/66771

/area mungegithub
/milestone 1.12
/assign

[spiffxp]

OK, milestone munger enforces that there must be:

• exactly one kind/ label out of (kind/bug, kind/cleanup, kind/feature)
• exactly onepriority/ label out of (priority/critical-urgent, priority/important-soon, priority/important-longterm)
• at least one sig/ label

I could:

• a) add kind/flake, kind/failing-test to list
• b) alter to look for at least one kind/ label
• c) do nothing and change the CI Signal docs to say that kind/bug is required on all issues that also have kind/failing-test and kind/flake
• d) replace this with commenter prowjobs for each label type, which would be unable to check "exactly one", and would only run periodically instead of in response to events, ie: use a query of milestone:v1.12 -label:kind/failing-test -label:kind/flake -label:kind/bug -label:kind/cleanup --label:kind/feature

Docs that need to be updated:

• https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/bug-triage (this already doesn't reflect the specific kind/ labels required)
• https://github.com/kubernetes/sig-release/blob/master/ephemera/issues.md

My vote would be a) and look at d) as a possible replacement for the milestone-maintainer munger

[spiffxp]

/assign @tpepper @AishSundar @guineveresaenger @mohammedzee1000
Hoping to avoid too much bikeshedding. How does a) sound?

[AishSundar]

+1 on doing (a). Since the CI Signal handbook explicitly says we need either kind/flake or kind/failing-test, we should be good.

Can you let us know what are you planning update in the bug-triage and ephemera docs?

[spiffxp]

When I take a course of action I'll /hold PR's with links back to this issue, and wouldn't plan on merging docs PR's until the change had been deployed.

[tpepper]

I agree on (a) being the near term way to go.

[mohammedzee1000]

I agree on (a) as well.

[guineveresaenger]

Agreeing with everyone, I look forward to not seeing these show up on my bug list

[spiffxp]

a) is going to require a redeploy of mungegithub

I will wait until we have a chance to discuss milestone-maintainer's future at today's sig-release meeting before deploying

[spiffxp]

So rather than (a), I'm going to recommend the previously unseen door (e), which is: disable the milestone-maintainer munger entirely, after discussing at today's sig-release meeting

https://github.com/kubernetes/sig-release/issues/243#issuecomment-409391292

This _also_ requires a redeploy of mungegithub, which isn't something I can do today. Hopefully tomorrow.

[spiffxp]

/close
I changed my mind about keeping this open for docs fixes. If there are bugs or new doc updates that need to happen, I'll look for separate issues. We disabled milestone-maintainer earlier today https://github.com/kubernetes/test-infra/pull/8909