vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For example, run ibmcloud ce job update -n JOB_NAME --build-clear. After you remove the association of the build from your job, you can update the job to reference a different image.
* If you are starting with source code that resides in a Git repository, you can choose to let Code Engine take care of building the image from your source and creating (or updating) the job with a single operation. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Creating a job from repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-source-code). If you want more control over the build of your image, then you can choose to [build the image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image) with Code Engine before you create (or update) your job and run the job.
* If you are starting with source code that resides on a local workstation, you can choose to let Code Engine take care of building the image from your source and creating the job with a single CLI command. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Creating your job from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-local-source-code). If you want more control over the build of your image, then you can choose to [build the image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image) with Code Engine before you create (or update) your job and run the job.



For example, you might choose to let Code Engine handle the build of your local source while you evolve the development of your source for the job. Then, after the image is matured, you can update the job to reference the specific image that you want. You can repeat this process as needed.
: To get the version locator for the product, run the ibmcloud catalog offering list command and locate the specified version that you want to use.

--output FORMAT (optional)
: Specifies output format. The default is terminal compatible and the only supported alternative is JSON, for example, --output json.







 ibmcloud catalog offering version add-controls 

Run the following command to add security and compliance controls to a version. Controls are safeguards that are used to meet security and compliance requirements.

ibmcloud catalog offering version add-controls [--version-locator VERSION_NUMBER] [--controls CONTROLS]



 Command options 

--version-locator VERSION_NUMBER
: To get the version locator for the product, run the ibmcloud catalog offering list command and locate the specified version that you want to use.

--controls CONTROLS
: Provide the controls as a JSON array. You can provide values as a JSON file or inline JSON. For example, [{"NIST": "AC-4"}, {"NIST": "AC-2"}].







 ibmcloud catalog offering version delete-controls 

Run the following command to delete security and compliance controls from a version. Controls are safeguards that are used to meet security and compliance requirements.

ibmcloud catalog offering version delete-controls [--version-locator VERSION_NUMBER] [--controls CONTROLS]



 Command options 

--version-locator VERSION_NUMBER
: To get the version locator for the product, run the ibmcloud catalog offering list command and locate the specified version that you want to use.

--controls CONTROLS
: Provide the controls as a JSON array. You can provide values as a JSON file or inline JSON. For example, [{"NIST": "AC-4"}, {"NIST": "AC-2"}].







 ibmcloud catalog offering version cra 

Run the following command to run a Code Risk Analyzer scan. The Code Risk Analyzer scans your source code and identifies any security vulnerabilities.
In the prior example, specify the SSH URL by using the git@ prefix for your source, such as --source git@github.com:IBM/CodeEngine.git.









 Resolution for a wrong revision during build 

A build configuration specifies the source repository by using its URL and optionally a revision. The revision can be either the name of a branch or tag, or a commit identifier. By default, the main branch is built. Review the error message for information about something that was specified but does not exist.



1. Use the [ibmcloud ce build update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-build-update) command to update the build configuration to use a correct revision (or commit); for example,

ibmcloud ce build update --name <BUILD_NAME> --commit <COMMIT>
2. Use the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command to submit a new build run. For the buildrun submit command, you must specify the --build option to provide the name of your build configuration. You can optionally specify the --name option to provide the name for this build run. If you specify the --name option, make sure that you use a different build run name from the failed build run, or ensure that you delete the failed build run by using the [ibmcloud ce buildrun delete](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-delete) command. For example,

ibmcloud ce buildrun submit --build <BUILD_NAME> --name <BUILDRUN_NAME>
Create a build configuration to build an image from source on your local workstation and specify the location of the image registry for the build output with a registry secret. With the build create command, when you specify local as the value for --build-type, you can only target IBM Cloud Container Registry for the output of your local build. Specify the --image option to provide the location of the image registry, and specify the --registry-secret option to access the registry. In this example, the command uses the default dockerfile strategy, and the default medium build size.

ibmcloud ce build create --name build-local-dockerfile --build-type local --image us.icr.io/mynamespace/codeengine-build --registry-secret myregistry
2. After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run-cli-local) with the CLI for source from a local directory (local).









 Running a build 

After you create a build configuration, you can submit a run based on that build configuration. Run your build from the console or with the CLI.

Code Engine has quotas for builds and build runs within a project. For more information about Code Engine limits, see [Limits and quotas for Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-limits).

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.



 Running a build from the console 



1. Go to the [Code Engine dashboard](https://cloud.ibm.com/codeengine/overview).
2. Select the project where you created your build.
3. From the project page, click Image builds.
4. Select your build configuration.
5.
Writing a Dockerfile for Code Engine 

Before you build your code into a container image, learn some basics of how a Docker build works within IBM Cloud® Code Engine. Then, look at some best practices for your Dockerfile to reach these goals.

When you create your build configuration, you decide which of the two available strategies to use.



1. Cloud Native Buildpacks inspect your source code and detect which runtime environment that your code is based on and how a container image is built from your sources. It is supported for several programming environments. You can find the supported list under [Choose a build strategy](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-buildbuild-strategy).
2. A Docker build creates a container based on how you describe it in a Dockerfile. The Dockerfile is then committed along with your source code to create the container.



While you can use either strategy for your build, you might choose Dockerfile, if, for example,



* Your programming environment is not supported by Buildpacks.
* Your project build must install additional packages in the container.





 Dockerfile basics 

A Dockerfile describes how a container is built. Within your Dockerfile, you choose a base image that includes the necessary tools that you need during your build and runtime. You can copy files from a build context into the image, run commands, define the runtime behavior such as environment variables, exposed ports, and set the ENTRYPOINT. The ENTRYPOINT is set by the command that is invoked when the container is started. For more information about how Dockerfile instructions can be specified, see [Dockerfile reference](https://docs.docker.com/engine/reference/builder/).

In a Code Engine build, you define a source that points to a Git repository. The context that is available to the Docker build is, by default, the root directory of your Git repository. For example, if you have a directory that is named src in your repository, then you can use the COPY statement in the Dockerfile to copy this directory into your image.
Build A build, or image build, is a mechanism that you can use to create a container image from your source code. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks. 
 Code repository A code repository, such as GitHub or GitLab, stores source code. With Code Engine, you can add access to a private code repository and then reference that repository from your build. 
 Configmap A configmap provides a method to include non-sensitive data information to your deployment. By referencing values from your configmap as environment variables, you can decouple specific information from your deployment and keep your app or job portable. A configmap contains information in key-value pairs. 
 Container image registry A container registry, or registry, is a service that stores container images. For example, IBM Cloud Container Registry and Docker Hub are container registries. A container registry can be public or private. A container registry that is public does not require credentials to access. In contrast, accessing a private registry does require credentials. 
 Function A Function is a stateless code snippet that performs tasks in response to an HTTP request. With IBM Code Engine Functions, you can run your business logic in a scalable and serverless way. IBM Code Engine Functions provide an optimized runtime environment to support low latency and rapid scale-out scenarios. Your Function code can be written in in Node.js or Python, which are optimized to run in IBM Code Engine Functions. In addition, your Function code can be written for any OpenWhisk compatible runtime environment or a custom runtime image. 
 Job A job runs one or more instances of your executable code. Unlike applications, which handle HTTP requests, jobs are designed to run one time and exit. When you create a job, you can specify workload configuration information that is used each time that the job is run. 
 Project A project is a grouping of Code Engine entities such as applications, jobs, and builds. A project is based on a Kubernetes namespace. The name of your project must be unique within your IBM Cloud® resource group, user account, and region. Projects are used to manage resources and provide access to its entities.
Creating a job from repository source code 

You can create your job directly from source code that is located in a Git repository with the IBM Cloud® Code Engine console and CLI. Find out what advantages are available when you [build your image with Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-faqsdockerbld-cebuild).



 Creating your job from repository source code from the console 

You can create your job directly from source code with the console.

Before you begin, [plan for your build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build). You can also find [tips for creating a Dockerfile](https://cloud.ibm.com/docs/codeengine?topic=codeengine-dockerfile). Each time that you run the job, the most current version of the dependent build artifacts, including the buildpacks and container image, are used during the build process and are included in the resulting container image.

Code Engine can automatically push (upload) images to IBM Cloud® Container Registry namespaces in your account and even create a namespace for you. To push images to a different Container Registry account or to a private Docker Hub account, see [Accessing container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).

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. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating from Start from source code.
3. Select Job.
4. Enter a name for the job. Use a name for your job that is unique within the project.
5. Select a project from the list of available projects.
Dynamic options 

An options response presents customers with a list of choices to select from. You can use the dynamic setting to generate the list from options that might be different each time.

Dynamic options are generated based on the data stored in a variable, which must be available to the step asking the question. The source variable must contain an array of values, each of which represents one of the options that will be presented to the customer. The items in the array can be simple values such as strings or numbers (for example, [ "Raleigh", "Boston", "New York" ]) or compound JSON objects.

A common scenario for dynamic options is when an array is returned from an external API that you call using a custom extension. For example, you might use a custom extension to retrieve a list of credit cards associated with a customer's account. You can then use dynamic options to ask the customer which card to use during the conversation. (For more information about custom extensions, see [Calling a custom extension](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-call-extension).)

Your actions might also populate the source variable using expressions. For example, you might use a session variable to build a shopping cart containing items the customer has decided to purchase. An action for removing an item from the cart could then use dynamic options to show the items in the cart so the customer can select which one to remove. (For more information about using expressions for variable values, see [Using an expression to assign a value to a session variable](https://cloud.ibm.com/docs/watson-assistant?topic=watson-assistant-expressionsexpression-variable).)



 Defining dynamic options 

To define a dynamic options customer response:



1. In a step, click Define customer response.
2. Choose the Options response type.
3. Click the Dynamic toggle.
4. In the Source variable field, choose the variable that contains the array that defines the dynamic options (for example, the variable containing the response from a custom extension that you called in a previous step).
5.
1. Log in to [IBM Cloud Toolchains](https://cloud.ibm.com/devops/toolchains) with your IBM Cloud credentials.
2. Select the Resource Group and Location for your toolchain.
3. Click Create toolchain.
4. On the Create a Toolchain page, select Satellite under Filters to display templates that are applicable for Satellite.
5. Select the Deploy Kubernetes resources to multiple clusters template.
6. Read through the information to understand how toolchains work and then click Start.







 Step 2: Defining toolchain settings 

Define the name, region, and resource group for the toolchain.



1. Provide the name for the toolchain.
2. Select the region where you want the toolchain to be created.
3. Select a resource group where you want the toolchain to be created.
4. Click Continue.







 Step 3: Defining your source repository 

Specify details of the source repository you want this toolchain to listen to. You can specify this info by using either standard configuration options or advanced configuration options.



1. Select your source provider. Depending on the source provider you choose, options specific to that source provider are displayed. For example, you can select Github Enterprise Whitewater as the source provider.
2. Define the source repository.



* To use a new repository for this toolchain, click Create new source repository and name the new repository.
* To use an existing repository for this toolchain, click Use existing source repository and provide the repository URL. Select the Source Provider and enter the URL of your repo, for example: https://github.com/my-org/my-repo.



3. Click Continue.



If you want to access more advanced source repository settings such as using a custom server and changing the cloning behavior, select Switch to advanced configuration.





 Step 4: Setting up your delivery pipeline 

Name the delivery pipeline for deploying your applications to multiple clusters in your Satellite cluster group.



1.
If your source is located in a public repository and you want to use a single command to build and output a container image, then use the buildrun submit command to create the container image without creating a reusable build configuration.

For the build output, you can choose automatic access and let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry. For this case, you do not need to specify a registry secret or the location of the image registry. Or, you can choose user-provided access and specify registry details along with a registry secret to access your built image in the registry.

For a complete listing of options for running a single build, see the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command.



 Running a single build with the CLI (with public repo source and automatic access to registry) 

In this automatic access scenario, Code Engine builds an image from your public Git repository source, and uploads the image to IBM Cloud Container Registry with automatic access by using build options with the buildrun submit command. In this case, you do not need to specify a registry secret or the location of the image registry.

See [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry) for more information about setting required permissions for Code Engine to automatically access these images in Container Registry.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).





1. Run a build to build an image from a public Git repo and let Code Engine automatically store and access the image.
If you want to update your source to use with your function, you must provide the --build-source option on the function update command.

When your function is deployed from local source or from [repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-source-code) from the CLI, the resulting build run is not based on a build configuration. Build runs that complete are ultimately automatically deleted. Build runs that are not based on a build configuration are deleted after 1 hour if the build run is successful. If the build run is not successful, this build run is deleted after 24 hours. You can only display information about this build run with the CLI. You cannot view this build run in the console.

Looking for more code examples? Check out the [Samples for IBM Cloud Code Engine GitHub repo](https://github.com/IBM/CodeEngine).
You can [migrate your IBM Cloud Functions to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-migrate).





 Building your first container image from source code 

Create and run your first Code Engine build and then deploy the container image in an application.

Code Engine can automatically push images to a Container Registry namespace in your account. It can even create a namespace for you. To push images to a different Container Registry account or to a private Docker Hub account, see [Adding access to a private container registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).



1. Open the [Code Engine](https://cloud.ibm.com/codeengine/overview) console.
2. Select Start creating.
3. 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 deploy an app.
4. Select Application.
5. Enter a name for the application. Use a name for your application that is unique within the project.
6. Select to run a Container image and specify icr.io/codeengine/helloworld for the image reference. For this example, you do not need to modify the default values. For more information about the code that is used for this example, see [helloworld](https://github.com/IBM/CodeEngine/tree/main/helloworld).
7. Select Source code.
8. Click Specify build details.
9. Accept the default for each page, clicking Next and then Done.
10. Click Create.



After your build run is submitted, the built container image is sent to Container Registry and then your application pulls the image and deploys for you. After the application status changes to Ready, you can try it out.
Users can purchase IBM Cloud for Education Virtual Course Credit by selecting the IBM Course Credit Subscription Plan

IBM Cloud for Education



* 2021-03-31



[Deploying and scaling applications](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-app-tutorial)Deploying and scaling applications

With this tutorial, deploy an application with the Code Engine CLI. The application scales to zero when not in use.

Code Engine



* 10 minutes
* 2023-06-22



[Running and updating jobs ](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-tutorial)Running and updating jobs

With this tutorial, run a batch job by using the IBM Cloud® Code Engine console.

Code Engine



* 10 minutes
* 2022-11-21



[Building applications by using buildpacks](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-app-tutorial)Building applications by using buildpacks

A build, or image build, is a mechanism that you can use to create a container image from your source code. Code Engine supports building from a Dockerfile and Cloud Native Buildpacks.

Code Engine



* 10 minutes
* 2023-03-08



[Configuring a highly available application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-multiple-regions)Configuring a highly available application

You can deploy your IBM Cloud® Code Engine application across multiple regions to make it resilient to regional failures. Note that this example uses IBM Cloud Internet Services, but you can use alternate providers. This example also uses a custom domain.

Code Engine Cloud Internet Services (CIS)



* 30 minutes
* 2023-04-20



[Running a function from local source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-fun-tutorial)Running a function from local source