vania-janet/multiturn-rag-retrieval-data huggingface dataset:
However, the build in Code Engine is not running on your local system, but instead in the Code Engine system. This build in Code Engine gives you several advantages.



1. You are not required to install software, such as Docker Desktop, locally.
2. You can use the resources that are provided by Code Engine. For example, you can take advantage of the speed of IBM Cloud to push and pull container registry images for you.
3. You can build your container image by using the [Buildpacks build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy) instead of Dockerfile, which detects your sources for various languages and automatically builds a container out of it.
4. If you have an image that was built with a non-Intel based processor, Code Engine can rebuild it for you.



* Why do images that are built by using a Code Engine buildpacks build show up in my container registry as being more than 15,000 days old?

Buildpacks create [reproducible builds](https://buildpacks.io/docs/reference/reproducibility/) of container images. When the same sources are built with the same version of the build tool, then the produced image has the same identifier. The identifier of an image is based not only on the files that are inside the image, but also based on dates in the metadata of the image. Part of this metadata is the creation timestamp. The [Buildpacks community](https://buildpacks.io/community) set all these dates in the image metadata to a fixed timestamp in 1980 to achieve reproducibility.
* Why do images that are built with non-Intel processors not work with Code Engine?

If you have an image that exists in a container registry and the image was built with a non-Intel based processor, Code Engine cannot run your container image. Code Engine uses Intel-based processing. You can build your own image if you use Intel processing (x86 processor). You can also choose to let Code Engine handle the build process for you.
Click Next.
10. Provide registry information about where to store the image of your build output. Select a container registry location, such as IBM Registry, Dallas. If your registry is private, you must [set up access](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry) to it.
11. Select an existing Registry access secret or create a new one. If you are building your image to an IBM Cloud Container Registry instance that is in your account, you can select Code Engine managed secret and let Code Engine create and manage the secret for you.
12. Select a namespace, name, and a tag for your image. If you are building your image to an IBM Cloud Container Registry instance that is in your account, you can select an existing namespace or let Code Engine create and manage the namespace for you.
13. Click Done.
14. Modify any default values for environment variables or runtime settings. For more information about these options, see [Options for creating and running a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-planjob-options).
15. Click Create.
16. After your build run is submitted, the built container image is sent to Container Registry and then your job can reference the built image. When the job is ready, click Submit job to run the job based on the current configuration.



Build runs that complete are ultimately automatically deleted. When your build run is based on build configuration, this build run is deleted after 3 hours if the build run is successful. If the build run is not successful, this build run is deleted after 48 hours.

Now that you have created your job and [run your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job), you can view details about your job configuration and job runs from your job page.

Need help? Check out [Troubleshooting tips for builds](https://cloud.ibm.com/docs/codeengine?topic=codeengine-troubleshoot-build).
When you are working with a Code Engine autogenerated (and managed) registry access secret, do not manually delete the registry access secret. Also, do not manually remove the service ID or its associated API key for the configured Container Registry region. Do not attempt to rotate the API key that is associated with this service ID. Instead, go to the Project settings > Integrations page in the console, and remove the configuration for the desired Container Registry access for your project, and then configure registry access again. This action deletes the old service ID and API key, and creates a new service ID and API key for registry access for the project in the desired region.





 Removing Code Engine managed access to Container Registry 

When you remove a Code Engine managed registry access secret for a particular region, this project-wide registry access is deleted. The associated service ID, API key, and registry secret are deleted. You can continue to use manually created registry access secrets, or you can configure project-wide Container Registry access again.



1. Go to the Integrations page.



1. Select your project from the [Projects page in the Code Engine console](https://cloud.ibm.com/codeengine/projects).
2. Click Project settings > Integrations.



2. From the row of the location (region) that you want to remove the registry access, click the Actions icon ![Actions](https://cloud.ibm.com/docs-content/v1/content/ad5f41087138b4b1bb795e3b5b0661ac5a105cbd/icons/action-menu-icon.svg) > Remove configuration. You are asked to confirm that you want to delete the registry access.



When you receive a message that registry access is removed, the status for registry access for a particular Container Registry location is Not configured.
oc secrets link builder <secret_name>
2. List the build configurations and note the ones that you want to give push and pull access to IBM Cloud Container Registry.

oc get bc
3. Set the image push secret for the build configuration to use the secret that you just created with Writer service access to IBM Cloud Container Registry.

oc set build-secret --push bc/<build_config_name> <secret_name>
4. Set the image pull secret for the build configuration to pull from the registry that you want to pull the initial build image from. For example, you can use the secret that you just created with Reader service access to IBM Cloud Container Registry if the source image is in an IBM Cloud Container Registry repository.

oc set build-secret --pull bc/<build_config_name> <secret_name>



6. After you update the build service account and build configuration file to push to IBM Cloud Container Registry, restart your build.

oc start-build <build_name>
7. Get the name of your build pod, such as <build>-2-build.

oc get pods
8. Check the logs of the build and note where the image was pushed.

oc logs <build_pod>

Example of a successful image push log.

...
Successfully pushed <region>.icr.io/<namespace>/<build_name>@sha256:<hash>
Push successful
9. Check your images in your private registry to confirm that the image is created.

ibmcloud cr image list

Example output

Repository Tag Digest Namespace Created Size Security status
<region>.icr.io/<namespace>/<build_name> latest <digest> <namespace> 2 minutes ago 182 MB 33 Issues



Your Red Hat OpenShift build can now pull images from and push images to IBM Cloud Container Registry.





 Using IBM Cloud Container Registry 

By default, your Red Hat OpenShift on IBM Cloud cluster is set up to pull images from the remote, private IBM Cloud Container Registry icr.io domains in the default project.
How do I enforce that my image traffic remains on the private network?
: The image push and pull traffic is automatically on the private network. IBM Cloud Kubernetes Service can use the public icr.io registry domains in existing image pull secrets to authenticate requests to IBM Cloud Container Registry. These requests are automatically redirected to the private icr.io registry domains. You don't need to modify the image pull secrets or configure additional settings.

Do I have to use the private icr.io registry addresses for anything else?
: Yes, if you [sign your images for trusted content](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_trustedcontent), the signatures contain the registry domain name. If you want to use the private icr.io domain for your signed images, resign your images with the private icr.io domains.







 Updating existing clusters to use the API key image pull secret 

New IBM Cloud Kubernetes Service clusters store an API key in [image pull secrets to authorize access to IBM Cloud Container Registry](https://cloud.ibm.com/docs/containers?topic=containers-registrycluster_registry_auth). With these image pull secrets, you can deploy containers from images that are stored in the icr.io registry domains. You can add the image pull secrets to your cluster if your cluster was not created with the secrets. For clusters that were created before 25 February 2019, you must update your cluster to store an API key instead of a registry token in the image pull secret.

Before you begin



1. [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)
2. Make sure that you have the following permissions: IBM Cloud IAM Operator or Administrator platform access role for IBM Cloud Kubernetes Service. The account owner can give you the role by running the following command.
To check whether policy-free authorization is in effect, run the [ibmcloud cr iam-policies-status](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_iam_policies_status) command. If the CLI reports that IAM policy enforcement is disabled, you must [prepare for the changes](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_notices_iam_policynotices_iam_policy_prepare).

The policy status setting is specific to each Container Registry region. Check every region in which you have Container Registry namespaces by running the [ibmcloud cr region-set](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_region_set) command.





 Prepare for the changes 

If the changes affect you, you must create IAM [access policies](https://cloud.ibm.com/docs/Registry?topic=Registry-user) that apply to each service ID and user ID that accesses images in your Container Registry namespaces, or accesses Container Registry settings that are associated with your account and region.



1. Identify each service ID and user ID that accesses your Container Registry images and settings. You can use [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/Registry?topic=Registry-at_events) to help find this information.
2. For each access that is identified in the previous step, [create an IAM access policy](https://cloud.ibm.com/docs/Registry?topic=Registry-user) that allows the correct access. You can also use access groups to apply policies to IDs.
3. (Optional) If you want to upgrade the account to use IAM access policy authorization at a more convenient time, rather than on the date of the change, run the [ibmcloud cr iam-policies-enable](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_iam_policies_enable) command.

This change cannot be reversed.
By using event subscriptions, you can trigger your apps by [periodic schedules](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-croneventing-cron-existing-app) or set your app to react to events such as [file uploads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producerobstorage_ev_app) or [Kafka messages](https://cloud.ibm.com/docs/codeengine?topic=codeengine-working-kafkaevent-producer).



After your app is deployed, you can [update your deployed app](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-app) and its referenced code by using any of the following ways, independent of how you created or previously updated your app:



* If you have a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/), then you need to provide only a reference to the image, which points to the location of your container registry when you deploy your app. You can deploy your app with an image in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app) or [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-private).

If you created your app by using the app create command and you specified the --build-source option to build the container image from local or repository source, and you want to change your app to point to a different container image, you must first remove the association of the build from your app. For example, run ibmcloud ce application update -n APP_NAME --build-clear. After you remove the association of the build from your app, you can update the app to reference a different image.
Container Registry private IP addresses changed on 5 July 2022 

By 23 June 2022, if you connect to IBM Cloud® Container Registry over the private network and you use Cloud Identity and Access Management (IAM) restricted IP address lists, you must change your IAM restricted IP list. This change also affects you if you have allowlists or a firewall rule.

On 23 June 2022, only the br-sao and ca-tor regions changed. The remaining regions changed on 5 July 2022. This change was originally due to take place on 23 May 2022 but was delayed.



 What you need to know about this change 

From 5 July 2022 (23 June 2022 for the br-sao and ca-tor regions), when connections are made to IBM Cloud Container Registry, the real source IP of the request is used. Previously, when connections came in over private networks, the source IP addresses that you saw in IBM Cloud Activity Tracker and that were configured for [IAM restricted IP address lists](https://cloud.ibm.com/docs/account?topic=account-ips) were documented Container Registry [IP addresses](https://cloud.ibm.com/docs/containers?topic=containers-firewallfirewall_private_container_registry).

This change improves the security of IBM Cloud Container Registry. With this change, you can configure real, account specific, private client IP addresses in IAM restricted IP lists, instead of the documented list of shared IP addresses. You must now allow private subnet and IP addresses of your own hosts (for example, worker nodes in a classic IBM Cloud Kubernetes Service cluster or the egress IP of a VPC network).

Also, as part of this change, the IBM Cloud Container Registry service private IP addressees changed, which might require updates to your firewall configuration.

If you use [Calico](https://www.tigera.io/project-calico/), the samples are updated to take account of the change.

You must not remove the IBM Cloud Container Registry private IP addresses from your IAM restricted IP list until an announcement advises you to do so.
Image Repository: image-registry.openshift-image-registry.svc:5000/default/ant1
Image Lookup: local=false
Unique Images: 1
Tags: 1

latest
tagged from <region>.icr.io/<namespace>/<image>:<tag>

* <region>.icr.io/<namespace>/<image>@<digest>
2 days ago



Now, your developers can [use the image stream in an app deployment](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesoc_imagestream_deploy). The image successfully builds from the locally pulled image in the internal registry. You don't need to set up an image pull secret in the project to IBM Cloud Container Registry, because the image stream is local to the cluster.





 Setting up builds in the internal registry to push images to IBM Cloud Container Registry 

When you create a [build](https://docs.openshift.com/container-platform/4.11/cicd/builds/understanding-image-builds.html) in your Red Hat OpenShift on IBM Cloud cluster, you can [set up the internal registry to push the image to your external repository](http://docs.openshift.com/container-platform/4.11/cicd/builds/creating-build-inputs.html) in IBM Cloud Container Registry. By default, the image pull secret in the default project of your cluster only has read access to pull images from IBM Cloud Container Registry. To push images, you must add a secret with write access.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Switch to the default project.

oc project default
3.
Calico is set up for you. You can't change the CNI plug-in, configure multiple networks, or attach a hardware network. 
 Ingress You can use the Ingress operator to set up one or more HAProxy-based Ingress controllers. You can route traffic to your apps by specifying Route or Ingress resources. When you create a cluster, a default Ingress subdomain is set up for you. One HAProxy-based router is set up for each Ingress controller, and one router service is automatically created in each zone that you have worker nodes in. You can route traffic to your apps by specifying Route or Ingress resources. For more information, see [About Ingress in Red Hat OpenShift version 4](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4). 
 Storage You must set up persistent volumes to be backed up by a storage provider. OpenShift Data Foundation is available. IBM automatically sets up storage providers such as IBM Cloud File and Block. OpenShift Data Foundation is available. For supported storage options, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan). 
 Image registry The cluster is set up with an internal registry to pull images. If your cluster has public network access, you can pull images automatically from Docker Hub. To pull images from other registries, you must set up image pull secrets. You set up the internal registry to back up images to a cloud storage provider. Stored images are not available across clusters. The internal registry is set up to back up images automatically to a bucket in your IBM Cloud Object Storage instance. Your cluster has image pull secrets automatically set up to pull images from default registries, including IBM Cloud Container Registry. You can also set up the internal registry to work with IBM Cloud Container Registry, which your cluster is also automatically set up to pull images from.
* Set up your [Code Engine CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli) environment.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
* Before you can work with a Code Engine job that references an image in Container Registry, you must first add access to the registry so Code Engine can pull the image when the job is run. For information about required permissions for accessing image registries, see [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).





1. To add access to Container Registry, [create an IAM API key](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryimages-your-account-api-key). To create an IBM Cloud IAM API key from the CLI, run the [iam api-key-create](https://cloud.ibm.com/docs/account?topic=cli-ibmcloud_commands_iamibmcloud_iam_api_key_create) command. For example, to create an API key called cliapikey with a description of "My CLI API key" and save it to a file called key_file, run the following command:

ibmcloud iam api-key-create cliapikey -d "My CLI API key" --file key_file

If you choose to not save your key to a file, you must record the API key that is displayed when you create it. You cannot retrieve it later.
2. After you create your API key, add registry access to Code Engine. To add access to Container Registry with the CLI, use the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command to create a registry secret.
Creating a job from images in a private registry 

Create your job that uses an image in a private registry such as private Docker Hub. You can create a job from the console or with the CLI.

Before you begin



* To pull images from a private registry, you must first create a private registry. For example, to create a private Docker Hub registry, see [Docker Hub documentation](https://docs.docker.com/docker-hub/repos/).
* After you create a private registry, [push an image to it](https://docs.docker.com/docker-hub/repos/pushing-a-docker-container-image-to-docker-hub).
* You can also set up an access token. By using an access token, you can more easily grant and revoke access to your Docker Hub account without requiring a password change. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).





 Creating a job that references an image in a private registry with the console 

Create a job configuration that uses an image in a private registry with the Code Engine console.

Before you can work with a Code Engine job that references an image in a private registry, you must first add access to the registry so Code Engine can pull the image when the job is run.



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Run a container image.
3. Select Job.
4. Enter a name for the job; for example, myjob.
5. Select a project from the list of available projects. You can also [create a new one](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-projectcreate-a-project). Note that you must have a selected project to create a job.
6. Select Container image and click Configure image.
7.
A default value of latest is just a tag name that the repository owner must manage. It does not mean that chronologically this Docker image is the latest image.

You can find a large community of repositories at Docker Hub. IBM hosts a number of public repositories that the IBM Cloud team uses at [https://hub.docker.com/u/ibmcom/](https://hub.docker.com/u/ibmcom/). The ibmcom/ibmjava and ibmcom/ibmnode repositories are useful to build on.





 Using a private image registry 

If you are using a private registry that requires authentication, you must set two extra stage environment properties: DOCKER_USERNAME and DOCKER_PASSWORD. You can use a secure property to mask your DOCKER_PASSWORD. Before your image is pulled, the custom Docker image job uses your user name and password credentials to complete a docker login.

For most registries, you can use the user name and password that were provided to you. If you use IBM Cloud Container Registry to store your private images, you must use a platform API Key for authentication.



1. [Request a platform API key](https://cloud.ibm.com/iam//apikeys) and make sure that you save the key.
2. Create the two stage environment properties by using iamapikey for your DOCKER_USERNAME and the platform API Key that you saved for the DOCKER_PASSWORD.

Zoom

![IBM Cloud Container Registry credentials](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/custom-image-private-repository.png)

Figure 2. Authentication credentials







 Specifying the script 

You can use the script block in custom Docker image jobs to create a script file that runs in a task folder, similar to how regular pipeline jobs work.

ENTRYPOINT and CMD from your Docker image's Dockerfile are overridden and are not called.