Auto-update dependencies

[mattmoor]

Produced via:
./hack/update-deps.sh --upgrade && ./hack/update-codegen.sh
/assign maximilien rhuss
/cc maximilien rhuss

[mattmoor]

/hold

Not sure what happened here, but this is clearly wrong 😅

[rhuss]

@mattmoor 🎵🎵... no deps, no cry ... 🎵🎵

[mattmoor]

@rhuss I'll futz with it a bit today to see if I can get things sorted out between all of my meetings 😢

[rhuss]

@mattmoor no rush at all, we need to get out 0.13.0 tomorrow first anyway.

[mattmoor]

That's more like it 😎

/unhold

[rhuss]

Thinking about it, I'm not sure that we continuously update on knative serving / eventing master and not stick to the latest released version, especially not in the the week between a Knative serving release and a Knative client release. For this "catch-up" week we should stick to the just-released version of Knative serving until the kn release. After that, I'm happy to switch back to a close master-branch sync.

@mattmoor what are you thoughts on this ? I mean, we really want to have kn 0.13.0 to depend on knative serving 0.13.0 (or 0.13.1 if there has been a hotfix in this week).

We could do this manually by just not merging the dep auto-updates in this 'between-releases' week, or maybe pause the bot for this week (maybe even automatically).

[mattmoor]

@rhuss this is exactly what we do with knative/pkg, and why I added VERSION, so that once the release branches exist we can track those until client releases with VERSION=release-0.13, which results in:

go get -d knative.dev/foo@release-0.13

0.13.x all cut from release-0.13, so this feels like what we want. Happy to discuss more.

[mattmoor]

Note that VERSION is the go mod way of doing what we do by changing the branch = in Gopkg.toml in other repos.

[mattmoor]

Also notable: pinning and unpinning is entirely under your control in the --upgrade script, this is just running that daily for you :)

[rhuss]

Cool, thanks ! yes, that makes totally sense to track the head of the release branch, if we ensure that we don't hit an intermediate state (e.g. some working state between two dot releases). Maybe it's better really to track the tags on those branches (assuming that activity on the release branch will end up in a patch release anyway soon).

Let me wrap my brain around the update, and will update the scripts accordingly

[rhuss]

/hold

[maximilien]

LGTM after release

[maximilien]

Can we have an update to README for the config defaults?

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mattmoor, maximilien

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mattmoor,maximilien]

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

[rhuss]

Fix have to fix the compile time error first.

[knative-prow-robot]

@mattmoor: The following tests failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-knative-client-integration-tests-latest-release	03a70ca	link	/test pull-knative-client-integration-tests-latest-release
pull-knative-client-integration-tests	03a70ca	link	/test pull-knative-client-integration-tests
pull-knative-client-unit-tests	03a70ca	link	/test pull-knative-client-unit-tests
pull-knative-client-build-tests	03a70ca	link	/test pull-knative-client-build-tests

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[rhuss]

Closed in favor of #750