Elide creating Build when the Build portion of the Configuration doesn't change.

[mattmoor]

This TODO.

[mattmoor]

cc @imjasonh

[mattmoor]

Just found out that riff is currently relying on this, so we should be sensitive to not breaking them.

cc @trisberg

[trisberg]

If we could add the annotation to the build part instead of the revisionTemplate then that would work fine for our purposes

[mattmoor]

@trisberg With decoupled build in 0.2 you can start doing this.

Before:

build:
  <spec>

After:

build:
  apiVersion: build.knative.dev/v1alpha1
  kind: Build
  metadata:
    annotations:
      # Since we will treat the entire "build" as opaque, any change should
      # trigger a new build, so this would serve a similar purpose to the nonce
      # @seyfer has proposed for forcing redeployments via the CLI.
      whatever/you: want
  spec:
    <spec>

[mattmoor]

(Separate comment for the original issue)

We should be able to achieve build elision by changing how we Create / Get builds for Revision to rely on a selector in place of the deterministic naming we have today.

As a strawman, we could serialize[1] the build and take its hash as hex, H then augment the build with:

metadata:
  labels:
    serving.knative.dev/buildVersion: H

We should then be able to efficiently query for an existing Build, and if not create it.

If multiple Builds exist with this label selector (user error), then the selection is undefined (we should just pick the first).

[1] - We actually already have this here, so we don't even have to serialize the build. We could consider adding a method to this helper to produce the hash.

[mattmoor]

/assign