Revert "ConfigMap Build Sources"

Author: deads2k

api/docs/apis-build.openshift.io/v1.Build.adoc

@@ -133,10 +133,6 @@ Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-gu
 </div><details><summary>  <span title="(v1.BuildSource) source describes the SCM in use.">source</span>:
 </summary><details><summary>    <span title="(v1.BinaryBuildSource) binary builds accept a binary as their input. The binary is generally assumed to be a tar, gzipped tar, or zip file depending on the strategy. For Docker builds, this is the build context and an optional Dockerfile may be specified to override any Dockerfile in the build context. For Source builds, this is assumed to be an archive as described above. For Source and Docker builds, if binary.asFile is set the build will receive a directory with a single file. contextDir may be used when an archive is provided. Custom builds will receive this binary as input on STDIN.">binary</span>:
 </summary><div style="margin-left:13px;">      <span title="(string) asFile indicates that the provided binary input should be considered a single file within the build input. For example, specifying &#34;webapp.war&#34; would place the provided binary as `/webapp.war` for the builder. If left empty, the Docker and Source build strategies assume this file is a zip, tar, or tar.gz file and extract it as the source. The custom strategy receives this binary as standard input. This filename may not contain slashes or be &#39;..&#39; or &#39;.&#39;.">asFile</span>:
-</div></details><details><summary>    <span title="(array) configMaps represents a list of configMaps and their destinations that will be used for the build.">configMaps</span>:
-</summary><details><summary>    - <span title="(v1.LocalObjectReference) configMap is a reference to an existing configmap that you want to use in your build.">configMap</span>:
-</summary><div style="margin-left:13px;">    -   <span title="(string) Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names">name</span>:
-</div></details><div style="margin-left:13px;">      <span title="(string) destinationDir is the directory where the files from the configmap should be available for the build time. For the Source build strategy, these will be injected into a container where the assemble script runs. For the Docker build strategy, these will be copied into the build directory, where the Dockerfile is located, so users can ADD or COPY them during docker build.">destinationDir</span>:
 </div></details><div style="margin-left:13px;">    <span title="(string) contextDir specifies the sub-directory where the source code for the application exists. This allows to have buildable sources in directory other than root of repository.">contextDir</span>:
 </div><div style="margin-left:13px;">    <span title="(string) dockerfile is the raw contents of a Dockerfile which should be built. When this option is specified, the FROM may be modified based on your strategy base image and additional ENV stanzas from your strategy environment will be added after the FROM, but before the rest of your Dockerfile stanzas. The Dockerfile source type may be used with other options like git - in those cases the Git repo will have any innate Dockerfile replaced in the context dir.">dockerfile</span>:
 </div><details><summary>    <span title="(v1.GitBuildSource) git contains optional information about git build source">git</span>:

api/docs/apis-build.openshift.io/v1.BuildConfig.adoc

@@ -137,10 +137,6 @@ Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-gu
 </div><details><summary>  <span title="(v1.BuildSource) source describes the SCM in use.">source</span>:
 </summary><details><summary>    <span title="(v1.BinaryBuildSource) binary builds accept a binary as their input. The binary is generally assumed to be a tar, gzipped tar, or zip file depending on the strategy. For Docker builds, this is the build context and an optional Dockerfile may be specified to override any Dockerfile in the build context. For Source builds, this is assumed to be an archive as described above. For Source and Docker builds, if binary.asFile is set the build will receive a directory with a single file. contextDir may be used when an archive is provided. Custom builds will receive this binary as input on STDIN.">binary</span>:
 </summary><div style="margin-left:13px;">      <span title="(string) asFile indicates that the provided binary input should be considered a single file within the build input. For example, specifying &#34;webapp.war&#34; would place the provided binary as `/webapp.war` for the builder. If left empty, the Docker and Source build strategies assume this file is a zip, tar, or tar.gz file and extract it as the source. The custom strategy receives this binary as standard input. This filename may not contain slashes or be &#39;..&#39; or &#39;.&#39;.">asFile</span>:
-</div></details><details><summary>    <span title="(array) configMaps represents a list of configMaps and their destinations that will be used for the build.">configMaps</span>:
-</summary><details><summary>    - <span title="(v1.LocalObjectReference) configMap is a reference to an existing configmap that you want to use in your build.">configMap</span>:
-</summary><div style="margin-left:13px;">    -   <span title="(string) Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names">name</span>:
-</div></details><div style="margin-left:13px;">      <span title="(string) destinationDir is the directory where the files from the configmap should be available for the build time. For the Source build strategy, these will be injected into a container where the assemble script runs. For the Docker build strategy, these will be copied into the build directory, where the Dockerfile is located, so users can ADD or COPY them during docker build.">destinationDir</span>:
 </div></details><div style="margin-left:13px;">    <span title="(string) contextDir specifies the sub-directory where the source code for the application exists. This allows to have buildable sources in directory other than root of repository.">contextDir</span>:
 </div><div style="margin-left:13px;">    <span title="(string) dockerfile is the raw contents of a Dockerfile which should be built. When this option is specified, the FROM may be modified based on your strategy base image and additional ENV stanzas from your strategy environment will be added after the FROM, but before the rest of your Dockerfile stanzas. The Dockerfile source type may be used with other options like git - in those cases the Git repo will have any innate Dockerfile replaced in the context dir.">dockerfile</span>:
 </div><details><summary>    <span title="(v1.GitBuildSource) git contains optional information about git build source">git</span>:

api/docs/oapi/v1.Build.adoc

@@ -133,10 +133,6 @@ Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-gu
 </div><details><summary>  <span title="(v1.BuildSource) source describes the SCM in use.">source</span>:
 </summary><details><summary>    <span title="(v1.BinaryBuildSource) binary builds accept a binary as their input. The binary is generally assumed to be a tar, gzipped tar, or zip file depending on the strategy. For Docker builds, this is the build context and an optional Dockerfile may be specified to override any Dockerfile in the build context. For Source builds, this is assumed to be an archive as described above. For Source and Docker builds, if binary.asFile is set the build will receive a directory with a single file. contextDir may be used when an archive is provided. Custom builds will receive this binary as input on STDIN.">binary</span>:
 </summary><div style="margin-left:13px;">      <span title="(string) asFile indicates that the provided binary input should be considered a single file within the build input. For example, specifying &#34;webapp.war&#34; would place the provided binary as `/webapp.war` for the builder. If left empty, the Docker and Source build strategies assume this file is a zip, tar, or tar.gz file and extract it as the source. The custom strategy receives this binary as standard input. This filename may not contain slashes or be &#39;..&#39; or &#39;.&#39;.">asFile</span>:
-</div></details><details><summary>    <span title="(array) configMaps represents a list of configMaps and their destinations that will be used for the build.">configMaps</span>:
-</summary><details><summary>    - <span title="(v1.LocalObjectReference) configMap is a reference to an existing configmap that you want to use in your build.">configMap</span>:
-</summary><div style="margin-left:13px;">    -   <span title="(string) Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names">name</span>:
-</div></details><div style="margin-left:13px;">      <span title="(string) destinationDir is the directory where the files from the configmap should be available for the build time. For the Source build strategy, these will be injected into a container where the assemble script runs. For the Docker build strategy, these will be copied into the build directory, where the Dockerfile is located, so users can ADD or COPY them during docker build.">destinationDir</span>:
 </div></details><div style="margin-left:13px;">    <span title="(string) contextDir specifies the sub-directory where the source code for the application exists. This allows to have buildable sources in directory other than root of repository.">contextDir</span>:
 </div><div style="margin-left:13px;">    <span title="(string) dockerfile is the raw contents of a Dockerfile which should be built. When this option is specified, the FROM may be modified based on your strategy base image and additional ENV stanzas from your strategy environment will be added after the FROM, but before the rest of your Dockerfile stanzas. The Dockerfile source type may be used with other options like git - in those cases the Git repo will have any innate Dockerfile replaced in the context dir.">dockerfile</span>:
 </div><details><summary>    <span title="(v1.GitBuildSource) git contains optional information about git build source">git</span>:

api/docs/oapi/v1.BuildConfig.adoc

@@ -137,10 +137,6 @@ Populated by the system. Read-only. More info: http://kubernetes.io/docs/user-gu
 </div><details><summary>  <span title="(v1.BuildSource) source describes the SCM in use.">source</span>:
 </summary><details><summary>    <span title="(v1.BinaryBuildSource) binary builds accept a binary as their input. The binary is generally assumed to be a tar, gzipped tar, or zip file depending on the strategy. For Docker builds, this is the build context and an optional Dockerfile may be specified to override any Dockerfile in the build context. For Source builds, this is assumed to be an archive as described above. For Source and Docker builds, if binary.asFile is set the build will receive a directory with a single file. contextDir may be used when an archive is provided. Custom builds will receive this binary as input on STDIN.">binary</span>:
 </summary><div style="margin-left:13px;">      <span title="(string) asFile indicates that the provided binary input should be considered a single file within the build input. For example, specifying &#34;webapp.war&#34; would place the provided binary as `/webapp.war` for the builder. If left empty, the Docker and Source build strategies assume this file is a zip, tar, or tar.gz file and extract it as the source. The custom strategy receives this binary as standard input. This filename may not contain slashes or be &#39;..&#39; or &#39;.&#39;.">asFile</span>:
-</div></details><details><summary>    <span title="(array) configMaps represents a list of configMaps and their destinations that will be used for the build.">configMaps</span>:
-</summary><details><summary>    - <span title="(v1.LocalObjectReference) configMap is a reference to an existing configmap that you want to use in your build.">configMap</span>:
-</summary><div style="margin-left:13px;">    -   <span title="(string) Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names">name</span>:
-</div></details><div style="margin-left:13px;">      <span title="(string) destinationDir is the directory where the files from the configmap should be available for the build time. For the Source build strategy, these will be injected into a container where the assemble script runs. For the Docker build strategy, these will be copied into the build directory, where the Dockerfile is located, so users can ADD or COPY them during docker build.">destinationDir</span>:
 </div></details><div style="margin-left:13px;">    <span title="(string) contextDir specifies the sub-directory where the source code for the application exists. This allows to have buildable sources in directory other than root of repository.">contextDir</span>:
 </div><div style="margin-left:13px;">    <span title="(string) dockerfile is the raw contents of a Dockerfile which should be built. When this option is specified, the FROM may be modified based on your strategy base image and additional ENV stanzas from your strategy environment will be added after the FROM, but before the rest of your Dockerfile stanzas. The Dockerfile source type may be used with other options like git - in those cases the Git repo will have any innate Dockerfile replaced in the context dir.">dockerfile</span>:
 </div><details><summary>    <span title="(v1.GitBuildSource) git contains optional information about git build source">git</span>: