anchor.diff:  
   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
  +Use the `*postCommit*` field to execute commands inside a temporary container
  +that is 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*`, which is 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.
  +The hook fails if the script or command returns a non-zero exit code or if
  +starting the temporary container fails. When the hook fails it marks the build
  +as failed and the image is not pushed to a registry. The reason for failing 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
  +pass and the test runner returns with exit code 0, the build is marked
  +successful. In case of any test failure, the build is 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 `*postCommit*` hook is not only limited to running tests, but can be used
  +for other commands as well. Since it runs in a temporary container, changes made
  +by the hook do not persist, meaning that 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.
  +usage of test dependencies that are automatically discarded and will be 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:
  +following examples are equivalent and execute `bundle exec rake test
  +--verbose`:
  +
  +* 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,
  +The `*script*` value 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. To control the image entry point,
   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
  +[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:
  +====
  +
  +* Command as the image entry point:
   +
   [source,yaml]
   ----
  
positive.code:   args: ["bundle", "exec", "rake", "test", "--verbose"]
  ----
  In this form, `*args*` is a list of arguments that are provided to the default
  entrypoint of the image. The image entrypoint must be able to handle arguments.
  +
  4. Shell script with arguments:
  +
  [source,yaml]
  ----
  
negative.code:   command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]
  ----
  +
  In this form, `*command*` is the command to run, which overrides the image
  entry point in the exec form, as documented in the
  link:https://docs.docker.com/engine/reference/builder/#entrypoint[Dockerfile
  reference]. This is needed if the image does not have `*/bin/sh*`, or if
  you do not want to use a shell. In all other cases, using `*script*` might be
  more convenient.
  
  * Pass arguments to the default entry point:
  +
  [source,yaml]
  ----
  