Add --upgrade to ./hack/update-deps.sh

[mattmoor]

For Knative, we have bots that update our inter-repo dependencies each weekday morning (PST), which enables us to very quickly detect and resolve breakages.

I hadn't enabled this for Tekton (thus far) because it used go mod, which was foreign enough to me that I avoided it like the plague. However, a number of factors have pushed me in the direction of having a standard ./hack/update-deps.sh mechanism for bumping certain dependencies, which enables us to support go mod (in Tekton as well as our own in the future).

This trivially enables us to enable the bots for Tekton because go mod becomes a hidden implementation detail.

For an example breaking change this would catch quickly: #2126

[tekton-robot]

Hi @mattmoor. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[mattmoor]

@vdemeester thoughts? I'd like to enable our automation to keep you folks closer to HEAD (and us aware of Tekton breakages).

[mattmoor]

Triggers needs something similar, but I wanted to discuss things here first 😉

[vdemeester]

/ok-to-test

(and us aware of Tekton breakages).

This I like. @mattmoor do you plan to have a bot that tries that ? It will only try release version or master ? (I am less a fan of upgrading daily to master knative/pkg but having something that upgrade to new release automatically is something I would like 👼)

[mattmoor]

@vdemeester This fast forwards branch dependencies, so master would track HEAD and release-0.X would track that release. There isn't a latest-release branch unfortunately.

[vdemeester]

@vdemeester This fast forwards branch dependencies, so master would track HEAD and release-0.X would track that release. There isn't a latest-release branch unfortunately.

right… we don't have that release-0… branch mechanisms as knative does on its repositories though.
From my understanding, go get -u the.dep/pkg will get the latest "release" (in the go modules sense), but I don't think knative/pkg does any tagging so… it will track master…

[vdemeester]

Also with the replace rules, I think go get is more or less a no-op (at least on go 1.13 that seemed to be the case, but I might be mistaken)

[mattmoor]

@vdemeester Correct, knative/pkg does branching not tagging.

The replace rules would have to drop for this to be effective, you are right that it is a no-op by itself.

That said, IIUC (please correct, I'm a go mod noob) the replace rules only affect updates so unless there is a reason to float the dependency forward, the dependency should remain frozen where it was.

If a breakage were introduced, we would detect it in the automatic PR within a day, and the breakage could either be fixed or the dependency pinned (with replace) to avoid folks hitting this.

[vdemeester]

That said, IIUC (please correct, I'm a go mod noob) the replace rules only affect updates so unless there is a reason to float the dependency forward, the dependency should remain frozen where it was.

If a breakage were introduced, we would detect it in the automatic PR within a day, and the breakage could either be fixed or the dependency pinned (with replace) to avoid folks hitting this.

So there is two things:

1. no replace for knative/* and have the bot upgrade it (daily, weekly, …)
2. if the bot PR fails, someone fix it (by doing a PR) and we are good
3. we would need to add a replace (or something) at release time (or maybe not) but at least we should make sure we track a released version of knative/pkg on releases.

@mattmoor does that make sense ?

[mattmoor]

Generally, yes. I haven't followed what your release cadence is, but we have been doing every 6 weeks with a knative/pkg cut on the 5th week, where we then pin downstream repos to release-0.Y (the next release). @n3wscott has some automation for this built around toml, but we will need to get on the go mod bandwagon at some point, so maybe this is the kick in the pants we need to extend that to Tekton.

[vdemeester]

Alright, I can see this being useful. We will need to update a bit our release process (automatically creating a release branch and "freeze" the knative/* dependency to a release-* branch).

Let's at least wait for release 0.11 to get done before merging this 👼

/hold

[mattmoor]

@vdemeester looking at go.mod, you don't have a lot of control here. Even your release-0.12 "constraint" isn't really a constraint. This script should actually enable you to float and freeze dependencies in a sensible way:

e.g.

FLOATING_DEPS=(
  # Pin to knative "0.13" release, but allow picking up cherry-picks.
  "knative.dev/pkg@release-0.13"
  "knative.dev/caching"  # we don't currently cut releases.
  "knative.dev/eventing-contrib@release-0.13"
)

[mattmoor]

/retest

[vdemeester]

@mattmoor yeah the script currently doesn't upgrade anything by itself, it's a "manual" run of a user to update a dep.

[vdemeester]

I really like that 👼

[mattmoor]

/retest

[mattmoor]

I wanted to ping this now that your release seems to be cut. LMK if I should change anything.

[vdemeester]

/hold cancel

[mattmoor]

So I just used the same process to enable this for our client repository, and you can see it in action here: knative/client#713. I've actually incorporated some of the improvements from that here (e.g. VERSION=...)

This regularly catches cross-repo breakages for us, which lets us fix them while the context is fresh.

[vdemeester]

/meow

/cc @sbwsg @bobcatfish for validation

[tekton-robot]

@vdemeester:

In response to this:

/meow

/cc @sbwsg @bobcatfish for validation

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.

[tekton-robot]

@vdemeester: GitHub didn't allow me to request PR reviews from the following users: for, validation.

Note that only tektoncd members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/meow

/cc @sbwsg @bobcatfish for validation

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.

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

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 [vdemeester]

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

[ghost]

/lgtm