mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-14492
This commit is contained in:
Janelle Neczypor
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
89bea9c710
commit
a92c18d4c2
@@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
The following sections define the primary supported build strategies, and how to
|
||||
use them.
|
||||
The following sections define the primary supported build strategies, and how to use them.
|
||||
|
||||
// Docker build strategy
|
||||
|
||||
|
||||
@@ -48,8 +48,5 @@ ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* xref:../../support/remote_health_monitoring/insights-operator-simple-access.adoc#insights-operator-simple-access[Importing simple content access certificates with Insights Operator]
|
||||
* xref:../../nodes/clusters/nodes-cluster-enabling-features.adoc#nodes-cluster-enabling[Enabling features using feature gates]
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
//TODO: Add this xref when the Images book is added to ROSA HCP.
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../openshift_images/image-streams-manage.adoc#image-streams-managing[Managing image streams]
|
||||
endif::openshift-rosa-hcp[]
|
||||
* xref:../../cicd/builds/build-strategies.adoc#build-strategies[Build strategies]
|
||||
|
||||
@@ -14,13 +14,10 @@ include::modules/builds-webhook-triggers.adoc[leveloffset=+2]
|
||||
|
||||
include::modules/unauthenticated-users-system-webhook.adoc[leveloffset=+3]
|
||||
|
||||
// TODO: Add xref to ROSA HCP when Authentication book is added.
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* xref:../../authentication/using-rbac.adoc#unauthenticated-users-cluster-role-bindings-concept_using-rbac[Cluster role bindings for unauthenticated groups]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
include::modules/builds-using-github-webhooks.adoc[leveloffset=+3]
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
toc::[]
|
||||
|
||||
|
||||
Builds is an extensible build framework based on the link:https://shipwright.io/[Shipwright project], which you can use to build container images on an {product-title} cluster. You can build container images from source code and Dockerfiles by using image build tools, such as Source-to-Image (S2I) and Buildah. You can create and apply build resources, view logs of build runs, and manage builds in your {product-title} namespaces.
|
||||
Builds is an extensible build framework based on the link:https://shipwright.io/[Shipwright project], which you can use to build container images on your {product-title} cluster. You can build container images from source code and Dockerfiles by using image build tools, such as Source-to-Image (S2I) and Buildah. You can create and apply build resources, view logs of build runs, and manage builds in your {product-title} namespaces.
|
||||
|
||||
Builds includes the following capabilities:
|
||||
|
||||
@@ -20,5 +20,5 @@ Builds includes the following capabilities:
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Because Builds releases on a different cadence from {product-title}, the Builds documentation is now available as a separate documentation set at link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift[builds for Red Hat OpenShift].
|
||||
Because Builds releases on a different cadence from {product-title}, the Builds documentation is now available as a separate documentation set at link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift[Builds for Red Hat OpenShift].
|
||||
====
|
||||
|
||||
@@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[]
|
||||
|
||||
toc::[]
|
||||
|
||||
{gitops-title} is an Operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using {gitops-title}, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. {gitops-title} is based on the open source project link:https://argoproj.github.io/cd/[Argo CD] and provides a similar set of features to what the upstream offers, with additional automation, integration into Red Hat {product-title} and the benefits of Red Hat’s enterprise support, quality assurance and focus on enterprise security.
|
||||
{gitops-title} is an Operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using {gitops-title}, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. {gitops-title} is based on the open source project link:https://argoproj.github.io/cd/[Argo CD] and provides a similar set of features to what the upstream offers, with additional automation, integration into Red Hat {product-title} and the benefits of Red Hat's enterprise support, quality assurance and focus on enterprise security.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -8,7 +8,7 @@ toc::[]
|
||||
|
||||
{product-title} provides a container image for running Jenkins. This image provides a Jenkins server instance, which can be used to set up a basic flow for continuous testing, integration, and delivery.
|
||||
|
||||
The image is based on the Red Hat Universal Base Images (UBI).
|
||||
The image is based on the Red Hat Universal Base Images (UBI).
|
||||
|
||||
{product-title} follows the link:https://jenkins.io/changelog-stable/[LTS] release of Jenkins. {product-title} provides an image that contains Jenkins 2.x.
|
||||
|
||||
@@ -71,8 +71,7 @@ include::modules/images-other-jenkins-memory.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
|
||||
// This xref points to a topic that is not currently included in the OSD and
|
||||
// ROSA docs.
|
||||
// This xref points to a topic that is not currently included in the OSD and ROSA docs.
|
||||
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
* See xref:../../architecture/understanding-development.adoc#base-image-options[Base image options] for more information about the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html-single/getting_started_with_containers/index#using_red_hat_base_container_images_standard_and_minimal[Red Hat Universal Base Images] (UBI).
|
||||
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
@@ -22,11 +22,8 @@ include::modules/customizing-the-jenkins-image-stream-tag.adoc[leveloffset=+1]
|
||||
[id="additional-resources_important-changes-to-openshift-jenkins-images_{context}"]
|
||||
== Additional resources
|
||||
|
||||
// TODO: Add xref to ROSA HCP when Images book is added.
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../openshift_images/managing_images/tagging-images.adoc#images-add-tags-to-imagestreams_tagging-images[Adding tags to image streams]
|
||||
* xref:../../openshift_images/image-streams-manage.adoc#images-imagestream-import_image-streams-managing[Configuring periodic importing of image stream tags]
|
||||
endif::openshift-rosa-hcp[]
|
||||
* xref:../../cicd/jenkins/images-other-jenkins-agent.adoc#images-other-jenkins-agent[Jenkins agent]
|
||||
* link:https://catalog.redhat.com/software/containers/search?q=Jenkins%202&p=1[Certified `jenkins` images]
|
||||
* link:https://catalog.redhat.com/software/containers/search?q=Jenkins%20Agent%20Base&p=1[Certified `jenkins-agent-base` images]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
:_mod-docs-content-type: ASSEMBLY
|
||||
//Jenkins-Tekton-Migration
|
||||
[id="migrating-from-jenkins-to-openshift-pipelines_{context}"]
|
||||
= Migrating from Jenkins to {pipelines-shortname} or Tekton
|
||||
= Migrating from Jenkins to OpenShift Pipelines or Tekton
|
||||
include::_attributes/common-attributes.adoc[]
|
||||
:context: migrating-from-jenkins-to-openshift-pipelines
|
||||
|
||||
@@ -24,7 +24,4 @@ include::modules/jt-examples-of-common-use-cases.adoc[leveloffset=+1]
|
||||
[role="_additional-resources"]
|
||||
== Additional resources
|
||||
* link:https://docs.openshift.com/pipelines/latest/about/understanding-openshift-pipelines.html[Understanding {pipelines-shortname}]
|
||||
// TODO: Add xref to ROSA HCP when Authentication book is added.
|
||||
ifndef::openshift-rosa-hcp[]
|
||||
* xref:../../authentication/using-rbac.adoc#using-rbac[Role-based Access Control]
|
||||
endif::openshift-rosa-hcp[]
|
||||
|
||||
@@ -17,7 +17,7 @@ toc::[]
|
||||
== OpenShift Builds
|
||||
OpenShift Builds provides you the following options to configure and run a build:
|
||||
|
||||
* Builds using Shipwright is an extensible build framework based on the Shipwright project. You can use it to build container images on an {product-title} cluster. You can build container images from source code and Dockerfile by using image build tools, such as Source-to-Image (S2I) and Buildah.
|
||||
* Builds using Shipwright is an extensible build framework based on the Shipwright project. You can use it to build container images on a cluster. You can build container images from source code and Dockerfile by using image build tools, such as Source-to-Image (S2I) and Buildah.
|
||||
+
|
||||
For more information, see link:https://docs.redhat.com/en/documentation/builds_for_red_hat_openshift[builds for Red Hat OpenShift].
|
||||
|
||||
@@ -39,6 +39,6 @@ For more information, see link:https://docs.redhat.com/en/documentation/red_hat_
|
||||
|
||||
[id="jenkins-ci-cd"]
|
||||
== Jenkins
|
||||
Jenkins automates the process of building, testing, and deploying applications and projects. OpenShift Developer Tools provides a Jenkins image that integrates directly with the {product-title}. Jenkins can be deployed on OpenShift by using the Samples Operator templates or certified Helm chart.
|
||||
Jenkins automates the process of building, testing, and deploying applications and projects. OpenShift Developer Tools provides a Jenkins image that integrates directly with {product-title}. Jenkins can be deployed on OpenShift by using the Samples Operator templates or certified Helm chart.
|
||||
|
||||
For more information, see xref:../../cicd/jenkins/images-other-jenkins.adoc#images-other-jenkins[Configuring Jenkins images].
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
//* builds/creating-build-inputs.adoc
|
||||
|
||||
[id="builds-adding-source-clone-secrets_{context}"]
|
||||
= Source Clone Secrets
|
||||
= Source clone secrets
|
||||
|
||||
Builder pods require access to any Git repositories defined as source for a build. Source clone secrets are used to provide the builder pod with access it would not normally have access to, such as private repositories or repositories with self-signed or untrusted SSL certificates.
|
||||
|
||||
|
||||
@@ -16,7 +16,9 @@ source:
|
||||
----
|
||||
<1> The `dockerfile` field contains an inline Dockerfile that is built.
|
||||
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
|
||||
* The typical use for this field is to provide a Dockerfile to a docker strategy build.
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
|
||||
@@ -65,5 +65,5 @@ endif::[]
|
||||
|
||||
When using an input image from a mirrored registry, if you get a `build error: failed to pull image` message, you can resolve the error by using either of the following methods:
|
||||
|
||||
* Create an input secret that contains the authentication credentials for the builder image’s repository and all known mirrors. In this case, create a pull secret for credentials to the image registry and its mirrors.
|
||||
* Create an input secret that contains the authentication credentials for the builder image's repository and all known mirrors. In this case, create a pull secret for credentials to the image registry and its mirrors.
|
||||
* Use the input secret as the pull secret on the `BuildConfig` object.
|
||||
|
||||
@@ -34,7 +34,7 @@ EOF
|
||||
$ oc get secret etc-pki-entitlement -n openshift-config-managed -o=go-template-file --template=secret-template.txt | oc apply -f -
|
||||
----
|
||||
|
||||
. Add the etc-pki-entitlement secret as a build volume in the build configuration’s Docker strategy:
|
||||
. Add the etc-pki-entitlement secret as a build volume in the build configuration's Docker strategy:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
|
||||
@@ -25,8 +25,7 @@ When using the first option, the `jenkinsfile` must be included in your applicat
|
||||
* A file named `jenkinsfile` at the root of the source `contextDir` of your repository.
|
||||
* A file name specified via the `jenkinsfilePath` field of the `JenkinsPipelineStrategy` section of your BuildConfig, which is relative to the source `contextDir` if supplied, otherwise it defaults to the root of the repository.
|
||||
|
||||
The `jenkinsfile` is run on the Jenkins agent pod, which must have the
|
||||
{product-title} client binaries available if you intend to use the {product-title} DSL.
|
||||
The `jenkinsfile` is run on the Jenkins agent pod, which must have the {product-title} client binaries available if you intend to use the {product-title} DSL.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -9,13 +9,11 @@ You can add a secret to your build configuration so that it can access a private
|
||||
|
||||
.Procedure
|
||||
|
||||
To add a secret to your build configuration so that it can access a private
|
||||
repository from the {product-title} web console:
|
||||
To add a secret to your build configuration so that it can access a private repository from the {product-title} web console:
|
||||
|
||||
. Create a new {product-title} project.
|
||||
|
||||
. Create a secret that contains credentials for accessing a private source code
|
||||
repository.
|
||||
. Create a secret that contains credentials for accessing a private source code repository.
|
||||
|
||||
. Create a build configuration.
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ The {product-title} Jenkins Sync Plugin keeps the build configuration and build
|
||||
|
||||
*{product-title} Jenkins Client Plugin*
|
||||
|
||||
The {product-title} Jenkins Client Plugin is a Jenkins plugin which aims to provide a readable, concise, comprehensive, and fluent Jenkins Pipeline syntax for rich interactions with an {product-title} API Server. The plugin uses the {product-title} command-line tool, `oc`, which must be available on the nodes executing the script.
|
||||
The {product-title} Jenkins Client Plugin is a Jenkins plugin which aims to provide a readable, concise, comprehensive, and fluent Jenkins Pipeline syntax for rich interactions with the {product-title} API Server. The plugin uses the {product-title} command-line tool, `oc`, which must be available on the nodes executing the script.
|
||||
|
||||
The Jenkins Client Plugin must be installed on your Jenkins master so the {product-title} DSL will be available to use within the `jenkinsfile` for your application. This plugin is installed and enabled by default when using the {product-title} Jenkins image.
|
||||
|
||||
|
||||
@@ -19,7 +19,14 @@ The OpenShift Jenkins Maven and NodeJS Agent images were removed from the {produ
|
||||
For more information, see the "Important changes to OpenShift Jenkins images" link in the following "Additional resources" section.
|
||||
====
|
||||
|
||||
The Maven and Node.js agent images are automatically configured as Kubernetes pod template images within the {product-title} Jenkins image configuration for the Kubernetes plugin. That configuration includes labels for each image that you can apply to any of your Jenkins jobs under their `Restrict where this project can be run` setting. If the label is applied, jobs run under an {product-title} pod running the respective agent image.
|
||||
The Maven and Node.js agent images are automatically configured as Kubernetes pod template images within the {product-title} Jenkins image configuration for the Kubernetes plugin. That configuration includes labels for each image that you can apply to any of your Jenkins jobs under their `Restrict where this project can be run` setting. If the label is applied, jobs run under
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
pod running the respective agent image.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
@@ -71,15 +71,36 @@ By default, the JVM sets the initial heap size.
|
||||
|Default: `300000` - 5 minutes
|
||||
|
||||
|`OVERRIDE_PV_CONFIG_WITH_IMAGE_CONFIG`
|
||||
|When running this image with an {product-title} persistent volume (PV) for the Jenkins configuration directory, the transfer of configuration from the image to the PV is performed only the first time the image starts because the PV is assigned when the persistent volume claim (PVC) is created. If you create a custom image that extends this image and updates the configuration in the custom image after the initial startup, the configuration is not copied over unless you set this environment variable to `true`.
|
||||
|When running this image with
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
persistent volume (PV) for the Jenkins configuration directory, the transfer of configuration from the image to the PV is performed only the first time the image starts because the PV is assigned when the persistent volume claim (PVC) is created. If you create a custom image that extends this image and updates the configuration in the custom image after the initial startup, the configuration is not copied over unless you set this environment variable to `true`.
|
||||
|Default: `false`
|
||||
|
||||
|`OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS`
|
||||
|When running this image with an {product-title} PV for the Jenkins configuration directory, the transfer of plugins from the image to the PV is performed only the first time the image starts because the PV is assigned when the PVC is created. If you create a custom image that extends this image and updates plugins in the custom image after the initial startup, the plugins are not copied over unless you set this environment variable to `true`.
|
||||
|When running this image with
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
PV for the Jenkins configuration directory, the transfer of plugins from the image to the PV is performed only the first time the image starts because the PV is assigned when the PVC is created. If you create a custom image that extends this image and updates plugins in the custom image after the initial startup, the plugins are not copied over unless you set this environment variable to `true`.
|
||||
|Default: `false`
|
||||
|
||||
|`ENABLE_FATAL_ERROR_LOG_FILE`
|
||||
|When running this image with an {product-title} PVC for the Jenkins configuration directory, this environment variable allows the fatal error log file to persist when a fatal error occurs. The fatal error file is saved at `/var/lib/jenkins/logs`.
|
||||
|When running this image with
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
PVC for the Jenkins configuration directory, this environment variable allows the fatal error log file to persist when a fatal error occurs. The fatal error file is saved at `/var/lib/jenkins/logs`.
|
||||
|Default: `false`
|
||||
|
||||
|`AGENT_BASE_IMAGE`
|
||||
|
||||
@@ -18,13 +18,27 @@ Users with the `admin` role have the traditional Jenkins administrative user per
|
||||
|
||||
The default {product-title} `admin`, `edit`, and `view` roles and the Jenkins permissions those roles are assigned in the Jenkins instance are configurable.
|
||||
|
||||
When running Jenkins in an {product-title} pod, the login plugin looks for a config map named `openshift-jenkins-login-plugin-config` in the namespace that Jenkins is running in.
|
||||
When running Jenkins in
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
pod, the login plugin looks for a config map named `openshift-jenkins-login-plugin-config` in the namespace that Jenkins is running in.
|
||||
|
||||
If this plugin finds and can read in that config map, you can define the role to Jenkins Permission mappings. Specifically:
|
||||
|
||||
* The login plugin treats the key and value pairs in the config map as Jenkins permission to {product-title} role mappings.
|
||||
* The key is the Jenkins permission group short ID and the Jenkins permission short ID, with those two separated by a hyphen character.
|
||||
* If you want to add the `Overall Jenkins Administer` permission to an {product-title} role, the key should be `Overall-Administer`.
|
||||
* If you want to add the `Overall Jenkins Administer` permission to
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifdef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
role, the key should be `Overall-Administer`.
|
||||
* To get a sense of which permission groups and permissions IDs are available, go to the matrix authorization page in the Jenkins console and IDs for the groups and individual permissions in the table they provide.
|
||||
* The value of the key and value pair is the list of {product-title} roles the permission should apply to, with each role separated by a comma.
|
||||
* If you want to add the `Overall Jenkins Administer` permission to both the default `admin` and `edit` roles, as well as a new Jenkins role you have created, the value for the key `Overall-Administer` would be `admin,edit,jenkins`.
|
||||
|
||||
@@ -6,7 +6,14 @@
|
||||
[id="unauthenticated-users-system-webhook_{context}"]
|
||||
= Adding unauthenticated users to the system:webhook role binding
|
||||
|
||||
As a cluster administrator, you can add unauthenticated users to the `system:webhook` role binding in {product-title} for specific namespaces. The `system:webhook` role binding allows users to trigger builds from external systems that do not use an {product-title} authentication mechanism. Unauthenticated users do not have access to non-public role bindings by default. This is a change from {product-title} versions before 4.16.
|
||||
As a cluster administrator, you can add unauthenticated users to the `system:webhook` role binding in {product-title} for specific namespaces. The `system:webhook` role binding allows users to trigger builds from external systems that do not use
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
an {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
ifndef::openshift-rosa,openshift-rosa-hcp[]
|
||||
a {product-title}
|
||||
endif::openshift-rosa,openshift-rosa-hcp[]
|
||||
authentication mechanism. Unauthenticated users do not have access to non-public role bindings by default. This is a change from {product-title} versions before 4.16.
|
||||
|
||||
Adding unauthenticated users to the `system:webhook` role binding is required to successfully trigger builds from GitHub, GitLab, and Bitbucket.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user