anchor.diff:  to `false` (the default setting) in the master configuration file, linking
   secrets to a service is not required.
   ====
  +
  +[[automatic-addition-of-a-source-secret-to-a-build-configuration]]
  +==== Automatically Adding Source Clone Secrets
  +
  +{product-title} can automatically add a source clone secret to relevant build
  +configurations if the source clone secret includes one or more annotations
  +prefixed with `build.openshift.io/source-secret-match-uri-`. The value of each
  +annotation indicates a URI pattern of a source repository against which the
  +secret matches. The URI pattern must consist of:
  +
  +- a valid scheme (`*://`, `git://`, `http://`, `https://` or `ssh://`).
  +- a host (`\*` or a valid hostname or IP address optionally preceded by `*.`).
  +- a path (`/\*` or `/` followed by any characters optionally including `*` characters).
  +
  +In all of the above, a `*` character is interpreted as a wildcard.
  +
  +[NOTE]
  +====
  +{product-title} will not automatically add a source clone secret to a build
  +configuration that already contains a source clone secret.
  +====
  +
  +If multiple source clone secrets match the URI of a particular source
  +repository, {product-title} will select the secret with the longest match. This
  +allows for basic overriding, as in the following example.
  +
  +The following fragment shows two partial source clone secrets, the first
  +matching any server in the domain `mycorp.com` accessed by HTTPS, and the second
  +overriding access to servers `mydev1.mycorp.com` and `mydev2.mycorp.com`:
  +
  +[source,yaml]
  +----
  +kind: Secret
  +apiVersion: v1
  +metadata:
  +  name: matches-all-corporate-servers-https-only
  +  annotations:
  +    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
  +data:
  +  ...
  +
  +kind: Secret
  +apiVersion: v1
  +metadata:
  +  name: override-for-my-dev-servers-https-only
  +  annotations:
  +    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
  +    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
  +data:
  +  ...
  +----
  +
  +Add a `build.openshift.io/source-secret-match-uri-` annotation to a pre-existing
  +secret using:
  +
  +----
  +$ oc annotate secret mysecret \
  +    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
  +----
   
   [[manual-addition-of-a-source-secret-to-a-build-configuration]]
   ==== Manually Adding Source Clone Secrets
  
positive.code: stream to the builder. The builder then extracts the contents of the archive
  within the build context directory.
  
  In each of the above cases:
  
  * If your `BuildConfig` already has a `Binary` source type defined, it will
  
negative.code: * If your `BuildConfig` has a `Git` source type defined, it is dynamically
  disabled, since `Binary` and `Git` are mutually exclusive, and the data in
  the binary stream provided to the builder takes precedence.
  
  Instead of a file name, you can pass a URL with HTTP or HTTPS schema to
  `--from-file` and `--from-archive`. When using  `--from-file` with a URL, the
  name of the file in the builder image is determined by the `Content-Disposition`
  header sent by the web server, or the last component of the URL path if the
  header is not present. No form of authentication is supported and it is not
  possible to use custom TLS certificate or disable certificate validation.
  
  When using `oc new-build --binary=true`, the command ensures that the
  restrictions associated with binary builds are enforced. The resulting
  