anchor.diff:      destinationDir: /etc
     type: Git
   ----
  -
  -You can also specify the destination directory when creating a new `BuildConfig`:
  -
  +====
  ++
  +You can also specify the destination directory when creating a new build
  +configuration:
  ++
  +====
   ----
   $ oc new-build openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git --build-secret “secret-npmrc:/etc”
   ----
  -
  -In both cases, the *_.npmrc_* file will be added into the *_/etc_* directory of
  -the build environment. Note that for a
  -link:../architecture/core_concepts/builds_and_image_streams.html#docker-build[Docker strategy]
  -the destination directory must be a relative path.
  +====
  ++
  +In both cases, the *_.npmrc_* file is added to the *_/etc_* directory of the
  +build environment. Note that for a
  +link:../architecture/core_concepts/builds_and_image_streams.html#docker-build[Docker
  +strategy] the destination directory must be a relative path.
   
   [[using-secrets-s2i-strategy]]
   === Source-to-Image Strategy
   
  -When you are using a `Source` strategy all defined source secrets will be copied
  -to the respective `destinationDir`. If you left `destinationDir` empty then the
  -secrets will be placed to the working directory of the builder image. The same
  -rule is used when a destination directory is a relative path - the secrets will
  -be placed into the paths that are relative to the image's working directory.
  -The `destinationDir` must exist or an error will occur. No directory paths are
  +When using a `Source` strategy, all defined source secrets are copied to their
  +respective `destinationDir`. If you left `destinationDir` empty, then the
  +secrets are placed in the working directory of the builder image. The same rule
  +is used when a `destinationDir` is a relative path; the secrets are placed in
  +the paths that are relative to the image's working directory. The
  +`destinationDir` must exist or an error will occur. No directory paths are
   created during the copy process.
   
  -Keep in mind that in the current implementation, files with the secrets are
  -world-writable (have `0666` permissions) and will be truncated to size zero
  -after execution of the *_assemble_* script. This means that the secret files will
  -exist in the resulting image but they will be empty for security reasons.
  +[NOTE]
  +====
  +Currently, any files with these secrets are world-writable (have `0666`
  +permissions) and will be truncated to size zero after executing the *_assemble_*
  +script. This means that the secret files will exist in the resulting image, but
  +they will be empty for security reasons.
  +====
   
   [[using-secrets-docker-strategy]]
   === Docker Strategy
   
  -When you are using a `Docker` strategy, you can add all defined source secrets into
  +When using a `Docker` strategy, you can add all defined source secrets into
   your Docker image using the https://docs.docker.com/engine/reference/builder/#add[ADD]
   and https://docs.docker.com/engine/reference/builder/#copy[COPY instructions]
   in your *_Dockerfile_*. If you don’t specify the `destinationDir` for a secret,
  
positive.code: This makes the secret files available to the Docker build operation as part of
  the context directory used during the build.
  
  Note that for security reasons, users should always remove their secrets from
  the final application image. This removal should be part of the *_Dockerfile_*
  itself. In that case, the secrets will not be present in the container running
  from that image. However, the secrets will still exist in the image itself in
  the layer where they were added.
  
  [[using-secrets-custom-strategy]]
  === Custom Strategy
  
  When you are using a `Custom` strategy, then all the defined source secrets will
  be available inside the builder container under
  *_/var/run/secrets/openshift.io/build_* directory. It is the custom build image's
  responsibility to use these secrets appropriately. The `Custom` strategy also
  allows secrets to be defined as described in link:#custom-secrets[Secrets]. There is
  no technical difference between existing strategy secrets and the source secrets.
  However, your builder image might distinguish between them and use them
  differently, based on your build use case. The source secrets are always mounted
  into *_/var/run/secrets/openshift.io/build_* directory or your builder can parse
  the `$BUILD` environment variable which includes the full Build object serialized
  into JSON format.
  
  
  [[starting-a-build]]
  
negative.code: [[using-secrets]]
  == Using Secrets During a Build
  
  In some scenarios, build operations require credentials to access dependent
  resources, but it is undesirable for those credentials to be available in the
  final application image produced by the build.
  
  For example, when building a NodeJS application, you can set up your private
  mirror for NodeJS modules. In order to download modules from that private
  mirror, you have to supply a custom *_.npmrc_* file for the build that contains
  a URL, user name, and password. For security reasons, you do not want to expose
  your credentials in the application image.
  
  This example describes NodeJS, but you can use the same approach for adding SSL
  certificates into the *_/etc/ssl/certs_* directory, API keys or tokens, license
  files, etc.
  
  [[using-secrets-in-the-buildconfig]]
  === Defining Secrets in the BuildConfig
  
  . Create the `Secret`:
  +
  ====
  ----
  $ oc secrets new secret-npmrc .npmrc=~/.npmrc
  ----
  ====
  +
  This creates a new secret named *_secret-npmrc_*, which contains the base64
  encoded content of the *_~/.npmrc_* file.
  
  . Add the secret to the `*source*` section in the existing build configuration:
  +
  [source,yaml]
  ====
  ----
  source:
    git:
  