Add integration test demonstrating use of PersistentVolumeClaims for inter-build caching

[imjasonh]

Functional example of #52

Proposed Changes

• Test defines a PersistentVolumeClaim which is attached first to a build that populates the cache, then another build reads the cache

Release Note

NONE

[google-prow-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ImJasonH

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:

• tests/OWNERS [ImJasonH]

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

[imjasonh]

/test pull-knative-build-integration-tests
/unassign srinivashegde86
/unassign steuhs
/assign mattmoor

[imjasonh]

/test pull-knative-build-integration-tests

Looks like this might be flaky on Prow? I didn't see any flakes after ~10 runs locally, but I guess if k8s schedules the second build before the first it won't see the cached content. Any ideas about how to order these builds better?

[mattmoor]

cc @adrcunha

[mattmoor]

Oh, I see the problem now. Let me think about it.

[imjasonh]

Probably needs to be a real Go test like knative/serving has, that waits for things to become ready before doing the next thing.

[mattmoor]

I got nothing that doesn't involve modifying the test harness (until we have a Pipeline CRD).

[imjasonh]

Adding support for real Go tests has other advantages too like being able to track noop build latency in testgrid. I'll work on that after Next.

[mattmoor]

@imjasonh you should sync with @srinivashegde86 who has been moving some of our common test code into knative/pkg to better enable this.

In the meantime, it might be interesting to write such a test in the knative/serving repo?

[imjasonh]

#341 instead