switch to gopkg.in/yaml.v3
https://github.com/kubernetes/test-infra/pull/33958/files#r1886682875
/priority backlog
we may also have to update dependency repos like sigs.k8s.io/prow
/sig testing
/assign
(https://github.com/kubernetes/test-infra/pull/33979#discussion_r1889325222)
This is because of the following reason
$ go mod why -m gopkg.in/yaml.v3
# gopkg.in/yaml.v3
k8s.io/test-infra/experiment/coverage
github.com/go-openapi/spec <====== (1)
github.com/go-openapi/swag
gopkg.in/yaml.v3
$ go mod why -m gopkg.in/yaml.v2
# gopkg.in/yaml.v2
k8s.io/test-infra/config/tests/mergelists
k8s.io/test-infra/config/tests/mergelists.test
github.com/GoogleCloudPlatform/testgrid/pkg/merger <====== (2)
gopkg.in/yaml.v2
(1) and (2) are imported modules that use these indirect dependencies. They are outside of the Kubernetes project, and we have minimal control over them.
Testgrid is us and can be patched cc @michelle192837
(1) I'm less sure about. cc @pohly @jpbetz
In kubernetes when we encounter this sort of issue we usually reach out to the intermediate projects to discuss. But I'm not sure if this is a reasonable ask in this case
Testgrid is us and can be patched cc @michelle192837
I see that they are using sigs.k8s.io/yaml module already, I can submit a PR to remove dependency from gopkg.in/yaml
https://github.com/GoogleCloudPlatform/testgrid/blob/3ad1f7c3c6a8b9085998213c1cc2cbd1eb80c3e4/go.mod#L33
Testgrid is us and can be patched cc @michelle192837
I see that they are using sigs.k8s.io/yaml module already, I can submit a PR to remove dependency from gopkg.in/yaml
https://github.com/GoogleCloudPlatform/testgrid/blob/3ad1f7c3c6a8b9085998213c1cc2cbd1eb80c3e4/go.mod#L33
submitted this PR in the testgrid - https://github.com/GoogleCloudPlatform/testgrid/pull/1301
I don't think we need to be pedantic about this. Not depending on it in code that we as Kubernetes own should be good enough. We explicitly should not as other projects to use sigs.k8s.io/yaml.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/lifecycle frozen
We should instead do https://github.com/kubernetes/kubernetes/issues/132056
FYI re: testgrid @michelle192837
Testgrid should probably do that eventually regardless just to be on a maintained library 🙃
Filed an issue to remind myself, thanks!