chore(deps): migrate to go.yaml.in/yaml/v3

[thevilledev]

gopkg.in/yaml.v3 is deprecated: https://github.com/go-yaml/yaml/tree/v3

Replace the direct dependency with go.yaml.in/yaml/v3 v3.0.4 which is the same code under the new module path. Remove the CVE-2022-28948 replace directive since v3.0.4 already includes the fix.

gopkg.in/yaml.v3 remains as an indirect dependency via transitive imports (e.g. go-openapi/swag) and will resolve as upstreams migrate:

$ go mod why -m gopkg.in/yaml.v3
# gopkg.in/yaml.v3
github.com/argoproj/notifications-engine/examples/certmanager/controller
k8s.io/client-go/kubernetes
k8s.io/client-go/discovery
github.com/google/gnostic-models/openapiv2
gopkg.in/yaml.v3

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.69%. Comparing base (da04400) to head (e5a2464).
⚠️ Report is 27 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #436      +/-   ##
==========================================
+ Coverage   55.41%   60.69%   +5.27%     
==========================================
  Files          46       48       +2     
  Lines        4125     3722     -403     
==========================================
- Hits         2286     2259      -27     
+ Misses       1511     1104     -407     
- Partials      328      359      +31     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[blakepettersson]

Could we migrate the lib in github.com/argoproj/notifications-engine/examples/certmanager/controller as well? Or perhaps we could do a wholesale replace in go.mod to go.yaml.in/yaml/v3 v3.0.4?

MIght be worth upgrading k8s.io/client-go to 0.34 to be in sync with Argo CD (that's for another PR though)

Otherwise LGTM

[thevilledev]

Thanks for the quick review @blakepettersson!

Just out of curiosity, which dependencies still depend on gopkg.in/yaml.v3?

So while go mod why gives only the shortest path to the dependency, this is what go mod graph gives:

$ go mod graph | grep 'gopkg.in/yaml.v3' |awk '{print $1}'|sort
dario.cat/[email protected]
github.com/argoproj/notifications-engine
github.com/go-openapi/[email protected]
github.com/go-openapi/[email protected]
github.com/go-openapi/[email protected]
github.com/google/[email protected]
github.com/prometheus/[email protected]
github.com/spf13/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
github.com/stretchr/[email protected]
go.opentelemetry.io/auto/[email protected]
go.opentelemetry.io/contrib/instrumentation/net/http/[email protected]
go.opentelemetry.io/[email protected]
go.opentelemetry.io/otel/[email protected]
go.opentelemetry.io/otel/[email protected]
gopkg.in/[email protected]
gopkg.in/[email protected]
k8s.io/[email protected]
k8s.io/[email protected]
k8s.io/[email protected]

I think the Cobra one is the only low hanging fruit. Testify has not migrated yet, so the indirect ref would stay there regardless: stretchr/testify#1772

Could we do a wholesale replace in go.mod to go.yaml.in/yaml/v3 v3.0.4?

Unfortunately no:

$ go mod edit -replace=gopkg.in/yaml.v3=go.yaml.in/yaml/[email protected]
$ go mod tidy
go: go.yaml.in/yaml/[email protected] used for two different module paths (go.yaml.in/yaml/v3 and gopkg.in/yaml.v3)

See this discussion: yaml/go-yaml#208