-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI check for undesired dependencies #4982
Comments
@KnVerey: This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The 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. |
One option is to leave this CI check as optional. If we see it failing, we file an issue for the problematic dependency and mark that issue as release blocking. |
/assign |
The script on k/k checks 4 things:
Should we cover all things for this issue or just the undesired dependencies? @natasha41575 @annasong20. |
I feel this problem is scoped in upgrading kustomize in Kubectl. Kubectl is currently importing kustomize with go pkg. I feel we are not required to care about other dependency problems in Kubectl. |
@koba1t are you referring to k/k's |
I think that is enough to refer to unwanted-dependencies.json in the k/k repo. |
/close |
@koba1t: Closing this issue. In response to this:
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. |
kubernetes/kubernetes has a list of unacceptable dependencies that they check in CI. Since we are subject to the same requirements, we should add the same check. This would help us avoid surprises when we go to update kustomize in kubectl.
https://github.com/kubernetes/kubernetes/blob/e51fe4a61cca7f4a0875630da433f280b52c138a/hack/lint-dependencies.sh
We will need to think carefully about how to source the dependencies list itself. If we pick it up live, everyones PR will instantly start to fail if k/k adds something we already depend on to the list, which happened with a few archived packages recently. Do we want that?
The text was updated successfully, but these errors were encountered: