Vendor the specified revision of knative/test-infra

[imikushin]

  # HEAD as of 2018-10-01
  revision = "c21d3a832727d5d4334e734c0878eac3a5a07ae7"

[knative-prow-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: imikushin
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: mattmoor

If they are not already assigned, you can assign the PR to them by writing /assign @mattmoor in a comment when ready.

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[imikushin]

/assign @mattmoor

[vdemeester]

@imikushin isn't it a duplicate of #2125 👼

[imikushin]

@vdemeester nope: this one specifies the exact revision in Gopkg.toml preventing the kind of problems I've just had

[adrcunha]

Yes, this is a dupe of #2125, the hashes are the same.

[adrcunha]

Anyway, #2125 is merged, you should be good now.

[imikushin]

/retest

[adrcunha]

This PR is not necessary anymore, and pinning the revision won't help much as knative/test-infra is not just an isolated repo with helper code, it's linked to the Prow jobs.

[imikushin]

@adrcunha While the content of ./vendor is indeed the same, pinning the revision does help: at least, it guarantees I'm vendoring from a revision known to work, so I don't spend time on this dependency when dep is failing. Please point where I'm wrong.

Also, every other required dependency has its revision pinned. Should we unpin those too?

[mattmoor]

@adrcunha How do we expect to keep Prow working on release branches?

[bbrowning]

@mattmoor Adding that as an agenda item for the next productivity WG meeting.