anchor.diff:  ----
   This form is equivalent to appending the arguments to `*command*`.
   
  -NOTE: It is invalid to provide both `*script*` and `*command*` simultaneously.
  +[NOTE]
  +==== 
  +Providing both `*script*` and `*command*` simultaneously creates an invalid
  +build hook.
  +====
   
   [[using-docker-credentials-for-pushing-and-pulling-images]]
   == Using Docker Credentials for Pushing and Pulling Images
  
positive.code: 
  Build hooks allow behavior to be injected into the build process.
  
  There is one hook type, post commit, that can be used to execute commands
  inside a temporary container running the build output image. The hook is
  executed immediately after the last layer of the image has been committed and
  before the image is pushed to a registry.
  
  The current working directory is set to the image's `*WORKDIR*`, the default
  working directory of the Docker image. For most images, this is where
  the source code is located.
  
  The hook will fail if the script or command returns a non-zero exit code or if
  there's any other error related to starting the temporary container. When the
  hook fails it will mark the build as failed and the image will not be pushed to
  a registry. The exact failure reason can be inspected by looking at the build
  logs.
  
  Build hooks can be used to run unit tests to verify the image before the build
  is marked complete and the image is made available in a registry. If all tests
  pass and the test runner returns exit code 0, the build will be marked
  successful. Otherwise, in case of any test failure, the build will be marked as
  failed. In all cases, the build log will contain the output of the test runner,
  which can be used to identify failed tests.
  
  The post commit hook is not limited to running tests but can be used for other
  commands as well. Changes made by the hook will not be persisted, since it runs
  in a temporary container. In other words, the hook execution cannot affect the
  final image. This behavior allows for, among other uses, the installation and
  usage of test dependencies that will be automatically discarded and not present
  in the final image.
  
  There are different ways to configure the post build hook. All forms in the
  examples below are equivalent and will execute `*bundle exec rake test
  --verbose*`:
  
  1. Shell script:
  +
  [source,yaml]
  ----
  postCommit:
    script: "bundle exec rake test --verbose"
  ----
  In this form, `*script*` is a shell script to be run with `*/bin/sh -ic*`. Use
  this when a shell script is appropriate to execute the build hook, for example
  for running unit tests as above. If you need control over the image entrypoint,
  or if the image does not have `*/bin/sh*`, use `*command*` and/or `*args*`.
  +
  NOTE: The additional `*-i*` flag was introduced to improve the experience
  working with CentOS and RHEL images, and may be removed in a future release.
  +
  2. Command as the image entrypoint:
  +
  [source,yaml]
  ----
  
negative.code:   args: ["bundle", "exec", "rake", "test", "--verbose"]
  ----
  In this form, `*args*` is a list of arguments that are provided to the default
  entry point of the image. The image entry point must be able to handle
  arguments.
  
  * Shell script with arguments:
  +
  [source,yaml]
  ----
  