Merge pull request #5059 from ahardin-rh/more-docker-build-cleaning

Removed Docker build references from Online docs

Author: ahardin-rh

creating_images/guidelines.adoc

@@ -92,22 +92,16 @@ operations.
 You can prevent the `yum` cache from ending up in an image layer by creating
 your `RUN` statement as follows:
 
-====
-
 ----
 RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y
 ----
-====
 
 Note that if you instead write:
 
-====
-
 ----
 RUN yum -y install mypackage
 RUN yum -y install myotherpackage && yum clean all -y
 ----
-====
 
 Then the first `yum` invocation leaves extra files in that layer, and these
 files cannot be removed when the `yum clean` operation is run later. The extra
@@ -138,29 +132,24 @@ For example, if you are working on a *_Dockerfile_* that contains an `ADD`
 command to install a file you are iterating on, and a `RUN` command to `yum
 install` a package, it is best to put the `ADD` command last:
 
-====
 
 ----
 FROM foo
 RUN yum -y install mypackage && yum clean all -y
 ADD myfile /test/myfile
 ----
-====
 
 This way each time you edit *_myfile_* and rerun `docker build`, the system reuses
 the cached layer for the `yum` command and only generates the new layer for the
 `ADD` operation.
 
 If instead you wrote the *_Dockerfile_* as:
 
-====
-
 ----
 FROM foo
 ADD myfile /test/myfile
 RUN yum -y install mypackage && yum clean all -y
 ----
-====
 
 Then each time you changed *_myfile_* and reran `docker build`, the `ADD`
 operation would invalidate the `RUN` layer cache, so the `yum` operation would
@@ -318,14 +307,15 @@ if ! whoami &> /dev/null; then
 fi
 ----
 
-For a complete example of this, see 
 ifdef::openshift-origin[]
-link:https://github.com/RHsyseng/container-rhel-examples/blob/master/starter-arbitrary-uid/Dockerfile.centos7[this Dockerfile]
+For a complete example of this, see
+link:https://github.com/RHsyseng/container-rhel-examples/blob/master/starter-arbitrary-uid/Dockerfile.centos7[this Dockerfile].
 endif::[]
 ifdef::openshift-enterprise[]
-link:https://github.com/RHsyseng/container-rhel-examples/blob/master/starter-arbitrary-uid/Dockerfile[this Dockerfile]
+For a complete example of this, see
+link:https://github.com/RHsyseng/container-rhel-examples/blob/master/starter-arbitrary-uid/Dockerfile[this Dockerfile].
 endif::[]
-.
+
 
 Lastly, the final *USER* declaration in the `Dockerfile` should specify the user
 ID (numeric value) and not the user name. This allows {product-title} to

creating_images/s2i_testing.adoc

@@ -67,12 +67,14 @@ useful, but it provides a good starting point to begin developing.
 ====
 The *_test/run_* script produced by the `s2i create` command requires that the sample application sources are inside the *_test/test-app_* directory.
 ====
-
+ifndef::openshift-online[]
 [[testing-locally]]
 
 == Testing Locally
 The easiest way to run the S2I image tests locally is to use the generated
-*_Makefile_*. If you did not use the `s2i create` command, you can copy the
+*_Makefile_*.
+
+If you did not use the `s2i create` command, you can copy the
 following *_Makefile_* template and replace the `*IMAGE_NAME*` parameter with
 your image name.
 
@@ -140,7 +142,7 @@ verify that saving and restoring artifacts works properly.
 Executing these steps is generally enough to tell if the builder image is
 working as expected.
 
-ifndef::openshift-online[]
+
 [[using-openshift-build-for-automated-testing]]
 
 == Using {product-title} Build for Automated Testing

dev_guide/builds/advanced_build_operations.adoc

@@ -133,7 +133,7 @@ the image or introduce vulnerabilities that can be exploited.
 To avoid these problems, two builds can be chained together: one that produces
 the compiled artifact, and a second build that places that artifact in a
 separate image that runs the artifact.
-
+ifndef::openshift-online[]
 In the following example, a
 xref:../../architecture/core_concepts/builds_and_image_streams.adoc#source-build[Source-to-Image]
 build is combined with a
@@ -262,7 +262,7 @@ whenever the first build is run and produces a new image with the binary
 artifact, the second build is automatically triggered to produce a runtime image
 that contains that artifact. Therefore, both builds behave as a single build
 with two stages.
-
+endif::[]
 [[build-pruning]]
 == Build Pruning