Merge pull request #39070 from bmcelvee/osdocs-2869-removing-residual-osd-ifdefs-main-bmcelvee

OSDOCS-2869: Removing some of the residual OSD conditionals froom builds, templates, and contributing

Author: pneedle-rh

cicd/builds/creating-build-inputs.adoc

@@ -61,7 +61,7 @@ include::modules/builds-adding-input-secrets-configmaps.adoc[leveloffset=+2]
 
 include::modules/builds-source-to-image.adoc[leveloffset=+2]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 
 include::modules/builds-docker-strategy.adoc[leveloffset=+2]
 
@@ -80,7 +80,7 @@ include::modules/builds-using-secrets-as-environment-variables.adoc[leveloffset=
 
 .Additional resources
 
-* xref:../../cicd/builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input secrets and config maps] 
+* xref:../../cicd/builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input secrets and config maps]
 
 include::modules/builds-service-serving-certificate-secrets.adoc[leveloffset=+1]
 

cicd/builds/setting-up-trusted-ca.adoc

@@ -24,28 +24,3 @@ include::modules/configmap-adding-ca.adoc[leveloffset=+1]
 * link:https://kubectl.docs.kubernetes.io/guides/config_management/secrets_configmaps/[Secrets and `ConfigMaps`]
 * xref:../../networking/configuring-a-custom-pki.adoc#configuring-a-custom-pki[Configuring a custom PKI]
 endif::[]
-
-
-ifdef::openshift-dedicated[]
-Use the following sections to set up additional certificate authorities (CA) to be trusted by builds when pulling images from an image registry.
-
-The procedure requires a Dedicated administrator to create a `ConfigMap` and add additional CAs as keys in the `ConfigMap`.
-
-* The `ConfigMap` must be created in the `openshift-config` namespace.
-* `domain` is the key in the `ConfigMap` and `value` is the PEM-encoded certificate.
-** Each CA must be associated with a domain. The domain format is `hostname[..port]`.
-* The `ConfigMap` name must be set in the `image.config.openshift.io/cluster` cluster scoped configuration resource's `spec.additionalTrustedCA` field.
-//* No longer needs single PEM bundle
-
-[NOTE]
-====
-{product-title} administrators are required to use the `registry-cas` `ConfigMap`.
-====
-
-include::modules/configmap-adding-ca.adoc[leveloffset=+1]
-
-== Additional resources
-
-* link:https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#create-a-configmap[Create a ConfigMap]
-* link:https://kubectl.docs.kubernetes.io/guides/config_management/secrets_configmaps/[Secrets and ConfigMaps]
-endif::[]

modules/builds-about.adoc

@@ -12,7 +12,7 @@ A build is the process of transforming input parameters into a resulting object.
 
 Build objects share common characteristics including inputs for a build, the requirement to complete a build process, logging the build process, publishing resources from successful builds, and publishing the final status of the build. Builds take advantage of resource restrictions, specifying limitations on resources such as CPU usage, memory usage, and build or pod execution time.
 
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin,openshift-enterprise[]
 The {product-title} build system provides extensible support for build strategies that are based on selectable types specified in the build API. There are three primary build strategies available:
 
 * Docker build

modules/builds-basic-access-build-verbosity.adoc

@@ -6,7 +6,7 @@
 = Enabling log verbosity
 
 You can enable a more verbose output by passing the `BUILD_LOGLEVEL` environment variable as part of the `sourceStrategy`
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin,openshift-enterprise[]
 or `dockerStrategy`
 endif::[]
 in a `BuildConfig`.

modules/builds-basic-start-source.adoc

@@ -5,7 +5,7 @@
 = Starting a build with source
 
 Rather than relying on a Git source pull
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin,openshift-enterprise[]
 or a Dockerfile
 endif::[]
 for a build, you can also start a build by directly pushing your source, which could be the contents of a Git or SVN working directory, a set of pre-built binary artifacts you want to deploy, or a single file. This can be done by specifying one of the following options for the `start-build` command:
@@ -34,7 +34,7 @@ Builds triggered from binary input will not preserve the source on the server, s
 .Procedure
 
 * Start a build from a source using the following command to send the contents of a local Git repository as an archive from the tag `v2`:
-+ 
++
 [source,terminal]
 ----
 $ oc start-build hello-world --from-repo=../hello-world --commit=v2

modules/builds-basic-view-build-details.adoc

@@ -15,7 +15,7 @@ This displays information including:
 * How the build was created.
 
 If the build uses the
-ifdef::openshift-origin,openshift-enterprise,openshift-dedicated[]
+ifdef::openshift-origin,openshift-enterprise[]
 `Docker` or
 endif::[]
 `Source` strategy, the `oc describe` output also includes information about the source revision used for the build, including the commit ID, author, committer, and message.

modules/builds-chaining-builds.adoc

@@ -9,7 +9,7 @@ For compiled languages such as Go, C, C++, and Java, including the dependencies
 
 To avoid these problems, two builds can be chained together. One build that produces the compiled artifact, and a second build that places that artifact in a separate image that runs the artifact.
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 In the following example, a source-to-image (S2I) build is combined with a docker build to compile an artifact that is then placed in a separate runtime image.
 
 [NOTE]

modules/builds-docker-source-build-output.adoc

@@ -6,7 +6,7 @@
 = Build output
 
 Builds that use the
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 docker or
 endif::[]
 source-to-image (S2I) strategy result in the creation of a new container image. The image is then pushed to the container image registry specified in the `output` section of the `Build` specification.

modules/builds-output-image-environment-variables.adoc

@@ -5,7 +5,7 @@
 [id="builds-output-image-environment-variables_{context}"]
 = Output image environment variables
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 docker and
 endif::[]
 source-to-image (S2I) strategy builds set the following environment variables on output images:
@@ -33,7 +33,7 @@ source-to-image (S2I) strategy builds set the following environment variables on
 
 Additionally, any user-defined environment variable, for example those configured with
 S2I]
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 or docker
 endif::[]
 strategy options, will also be part of the output image environment variable list.

modules/builds-output-image-labels.adoc

@@ -5,7 +5,7 @@
 [id="builds-output-image-labels_{context}"]
 = Output image labels
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 docker and
 endif::[]
 source-to-image (S2I)` builds set the following labels on output images: