prow: enable issue-management plugin for kubernetes-sigs/external-dns

[ivankatliarchuk]

Why: Contributors to external-dns have no way to link/unlink GitHub issues to PRs via prow commands.

What: Adds a kubernetes-sigs/external-dns entry to plugins.yaml enabling the issue-management plugin, which provides /link-issue and /unlink-issue commands (org members only).

https://github.com/kubernetes-sigs/external-dns/blob/master/OWNERS

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ivankatliarchuk
Once this PR has been reviewed and has the lgtm label, please assign chases2 for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• config/OWNERS

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

[cblecker]

/hold
I don't believe we have this turned on anywhere else, and there are still follow up issues with this new plugin. To be honest, I'm not even convinced it's needed. The PR author can edit the PR body themselves. Why wouldn't the maintainer just ask them? Or /close the issue when it merges manually?

[ivankatliarchuk]

This is exactly what the plugin is for. We do /retitle. Yeas, I could close as project maintainer an issue, but I could not link it.

The response is based on the assumption, that everyone is aware how to correctly link an issue to a PR, which is wrong in principle. We have a good volume of PRs, and it's simply easier attach an issue then keep asking random folks to do it multiply times.

I'm not aware of any bugs on that plugin. It was added month ago kubernetes-sigs/prow#556

Could you please clarify what is wrong with the plugin and why we cannot use on project we maintain?

[ivankatliarchuk]

To be honest, I'm not even convinced it's needed.

I'm sotry but this passive-aggressive and dismissive tone on public space not sure if acceptable. Please be professional. I accept your suggestion and not agree with it. We ve identified a clear need for this plugin, so we'd want to understand the specific problem or clear technical reasons why it cannot be enabled.

[cblecker]

Hi @ivankatliarchuk !

My intent was not to be passive aggressive, but as a prow maintainer a of the prow configuration for the Kubernetes project, I need to give feedback on the workflow and process. My apologies if you were offended in any way.

Just because we make a plugin available inside of prow (which is used more widely than the Kubernetes project), doesn't necessarily mean we believe that workflow to be useful to enable for the Kubernetes project itself.

My thought process around this: as approvers in repos, there is a certain responsibility to educate contributors. The "fixes" closing functionality has been a core part of the GitHub workflow for many years, and educating new contributors in how this works is helpful for their open source journey and growth.

As for what would need to be changed, see @petr-muller 's review here: kubernetes-sigs/prow#556 (review)

[ivankatliarchuk]

Thanks for explanation. I'll submit a fix for remaning items then.

Contributor education isn't really scalable here, at least from my opinion as contributors come and go, and behavior varies widely across the community. What I'm actually asking for is a specific capability scoped to maintainers, not a process change that depends on every stranger following it consistently.

I think plugins that helps witht doing basics actions supported by prow are of great help. The other option for us is sort of shadow tech, that is happening across kubernetes projects.

[ivankatliarchuk]

This PR kubernetes-sigs/prow#672 addresses missing items.

There is new plugin recently was added kubernetes-sigs/prow#623 that I asked for while ago.

Are we ok to proceed and trial them? They not a killer features, same time nice little additions to our worfkflow.

[petr-muller]

I am not much involved in any decisions about how exactly Prow is configured across k8s but enabling it in a single repository that wants it sounds like a good proving ground to me. I see no concerns with that, except maybe for creating a small DX inconsistency between k8s repos, but for this specific case it does not sound like a big deal.