Avoid breaking changes in public interfaces: use apidiff as presubmit for client-go staging repo

[aojea]

>          This change breaks the upgrade to 1.30 for every controller built on top of controller-runtime e.g. Flux https://github.com/fluxcd/pkg/pull/763. Hopefully the controller-runtime maintainers will do a release soon that deals with this breaking change.

Originally posted by @stefanprodan in #122069 (comment)

Ideally we should have a linter or some presubmit that detects this breakages and block the PR waiting for API review, it just have to add the label kind/api-change

/cc @liggitt

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[aojea]

/sig testing
/sig api-machinery

/help

[k8s-ci-robot]

@aojea:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/sig testing
/sig api-machinery

/help

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.

[dims]

@aojea already in progress xref: #124372

[aojea]

@dims this is about warning on these changes in general, not about that specific one, as it is easy some of these things slip during reviews, we can have a job that detects these changes on staging client-go

[dims]

@aojea Ack. we have apidiff in various repositories for example:
https://cs.k8s.io/?q=apidiff&i=nope&files=.*%5C.sh&excludeFiles=&repos=

[aojea]

Reference

didn't know that event existed :) , so we just need to make it available, at least in the client-go repo , we can start with informative to see how it goes, WDYT?

[dims]

WDYT?

yep!

[liggitt]

go APIs have always been out of scope for API review, we don't have the capacity to route everything that apidiff would flag as a go API change through that process

I guess I don't object to running it as informative, but I think many more PRs than you expect change a public signature, and will turn the job red, to the point where it will just be ignored

[aojea]

I'm thinking in client-go only , as use to be the most problematic since is vendored by controller runtime and all projects that build controllers

[pohly]

FWIW, I had a PR for enabling apidiff with the intention to add it as an optional, on-demand job. Jordan raised the same concerns there, so I closed it.

[pohly]

"Optional, on-demand" might have worked in #122069 (comment) if the folks involved had known and remembered to run it.

The API break was caught during review, the scope of it was just underestimated. Perhaps seeing the apidiff output would have helped? 🤷

[aojea]

f the folks involved had known and remembered to run it.

can you reopen so we can make it "Optional, on-demand" , at least I will selfishly use it :)

[fedebongio]

Is there any pending action on this one or can we close it?

[aojea]

/close

[k8s-ci-robot]

@aojea: Closing this issue.

In response to this:

/close

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-sigs/prow repository.