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: [[using-secrets]]
  == Using Secrets During a Build
  
  In some scenarios operations performed by the build 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, you are building a NodeJS application and you 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,
  username and password. For security reasons, you do not want to expose your
  credentials in the application image.
  
  While this example describes NodeJS, 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
  
  First, you have to create the `Secret` you want to use. You can do that by
  executing the following command:
  
  ----
  $ oc secrets new secret-npmrc .npmrc=~/.npmrc
  ----
  
  This command will create a new `Secret` named *_secret-npmrc_* and store
  the base64 encoded content of the *_~/.npmrc_* file in it.
  
  Now, that you have the secret created, you can add references to `*secrets*`
  into the `*source*` section in the existing `BuildConfig`:
  
  [source,yaml]
  ----
  source:
    git:
  
negative.code: This makes the secret files available to the Docker build operation as part of
  the context directory used during the build.
  
  [NOTE]
  ====
  Users should always remove their secrets from the final application image so
  that the secrets are not 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. This removal should be part of the *_Dockerfile_* itself.
  ====
  
  [[using-secrets-custom-strategy]]
  === Custom Strategy
  
  When using a `Custom` strategy, then all the defined source secrets are
  available inside the builder container in the
  *_/var/run/secrets/openshift.io/build_* directory. The custom build image is
  responsible for using 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 the *_/var/run/secrets/openshift.io/build_* directory or
  your builder can parse the `$BUILD` environment variable, which includes the
  full build object.
  
  
  [[starting-a-build]]
  