vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Creating a job from images in a public registry 

When you create a job, you can specify workload configuration information that is used each time that the job is run. You can create a job from the console or with the CLI.



 Creating a job with the console 

Create a Code Engine job by using the icr.io/codeengine/firstjob image. This job prints Hi from a batch job! My index is:.



1. Open [Code Engine](https://cloud.ibm.com/codeengine/overview).
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. Specify a container image for your job, for example, icr.io/codeengine/firstjob. If you have your own source code that you want to turn into a container image for the job, see [building a container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image). For more information about the code that is used for this example, see [firstjob](https://github.com/IBM/CodeEngine/tree/main/job).
7. 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).
8. Click Create.
9. From your job page, when your job is in ready status, click Submit job to submit a job based on the current configuration.
10.
OK

https://myapp.abcdbwa0lci.us-south.codeengine.appdomain.cloud

And that's it. You now have an internet-facing application. The code in the application itself is the same as what is used for a Cloud Foundry application, it's just the Code Engine commands that are slightly different.

Let's take a deeper look at the previous app create command. Notice that the output of the app create command provides information about the progression of the build run before the app is created and deployed.



1. Code Engine receives a request to create an application from source code (instead of pulling directly from an image).
2. Code Engine checks for an IAM service ID and API key that is associated with the selected project. This service ID must be authorized to read and write to IBM Cloud Container Registry. If no service ID exists, Code Engine creates one for you. Note that this service ID is used for subsequent Code Engine build requests that are run from the same project.
3. This example builds code from a local source (--build-source .). The source code is packed into an archive file and uploaded to a managed namespace within the IBM Cloud Container Registry instance in your account. Note that you can target only IBM Cloud Container Registry for your local builds. For more information about IBM Container Registry, including information about quota limits and access, see [Getting started with IBM Cloud Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started).
4. Code Engine builds your source code into an image. The source image is created in the same namespace as your source archive file.
5. After the build completes, your application is deployed. You can access your application from the provided URL.



With Code Engine, you automatically get many of the same features as Cloud Foundry, such as autoscaling and blue-green roll-out of updates, but you'll also enjoy the benefits of newer features such as scaling down-to-zero, ensuring that you are not charged if your application is not active.

Want to learn more about your options for building your source code?
: 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. You must add controls and validate your version before you can run the scan.

ibmcloud catalog offering version cra [--version-locator VERSION_NUMBER] [--wait WAIT] [--timeout TIMEOUT]



 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.

--wait WAIT
: Wait and track the progress of the Schematics workspace job. If true, installation waits. If false, the software installs immediately. Default is true.

--timeout TIMEOUT
: Specify in seconds how long the Schematics workspace waits before it installs. Default is 180.







 ibmcloud catalog offering version cra-status 

Run the following command to retrieve the status of a Code Risk Analyzer scan.

ibmcloud catalog offering version cra-status [--version-locator VERSION_NUMBER] [--output OUTPUT]



 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.

--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 scc 

Run the following command to add a scan that you previously ran in Security and Compliance Center to a version. Each scan is limited to a single profile. For more information, see [What is a profile?]
Getting started with IBM Cloud Code Engine 

IBM Cloud® Code Engine is a fully managed, serverless platform that runs your containerized workloads, including web apps, micro-services, event-driven functions, or batch jobs. Code Engine even builds container images for you from your source code. All these workloads can seamlessly work together because they are all hosted within the same Kubernetes infrastructure. The Code Engine experience is designed so that you can focus on writing code and not on the infrastructure that is needed to host it.

First, learn about some [key terms](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedterm-summary) for Code Engine and then get started with one of the following options.



* [Deploy an application](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedapp-hello)
* [Create and run a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedfirst-job)
* [Run Function code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedfirst-function)
* [Building your first container image from source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-getting-startedbuild-image-gs)





 What are Code Engine projects, applications, jobs, and functions? 

Before you get started, become familiar with some key terms for Code Engine. Afterward, you can test your knowledge and [!take a quiz](https://ibm.biz/BdfFxR)



Table 1. Code Engine Terms

 Term Description 

 Project A project is a grouping of Code Engine entities such as applications, jobs, and builds. Projects are used to manage resources and provide access to its entities. 
 Application An application, or app, runs your code to serve HTTP requests. An application has a URL for incoming requests.
Source Image: private.us.icr.io/ce--27fe9-glxo4k7nj7d/buildrun-buildrun-local-dockerfile-source
Source Registry Secret: ce-auto-icr-private-us-south
Dockerfile: Dockerfile

Notice the generated name for the image and that the name of the automatically created registry secret is of the format, ce-auto-icr-private-<region>.







 Running a single build with the CLI (with local source and user-provided access to registry) 

In this user-provided access scenario, Code Engine builds an image from your local source, and then uploads the image to your container registry with the registry access that you provide with the buildrun submit command.

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).
* [Create a registry secret so you can save your image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry).



Before you work with local source, make sure that your source is in an accessible location on your local workstation.

This example uses the https://github.com/IBM/CodeEngine samples; in particular, the helloworld sample.



1. Download the https://github.com/IBM/CodeEngine sample source to your local workstation with the following command.

git clone https://github.com/IBM/CodeEngine
2. Change to the CodeEnginehelloworld directory.
3. From the CodeEnginehelloworld directory, run a build run to build an image from the helloworld source on your local workstation and specify the location of the image registry for the build output with a registry secret.
Building a container image 

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.

When your code exists as source in a local file or in a Git repository, Code Engine provides options for you to build your code as a container image, per the [Open Container Initiative (OCI) standard](https://opencontainers.org/).

When you want Code Engine to handle the build process for you,



* 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 deploying the app with a single operation. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Deploying your app from repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-source-code) and [Creating a job from repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-source-code).
* 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 deploying the app with a single CLI command. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Deploying your app from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-local-source-code) and [Creating your job from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-local-source-code).



However, if you want more control over the build of your image, you must first create a build configuration and then run your build. After your build is complete, you can deploy the container image as an application or create a job that references your image.
By using event subscriptions, you can trigger your jobs by [periodic schedules](https://cloud.ibm.com/docs/codeengine?topic=codeengine-subscribe-croneventing-cron-job) or set your job to react to events like [file uploads](https://cloud.ibm.com/docs/codeengine?topic=codeengine-eventing-cosevent-producerobstorage_ev_job).
* You can [update your job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-job) and its referenced code in any of the following ways, independent of how you created or previously updated your job.



* 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 create (or update) your job. You can create (or update) your job from images in a [public registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job) or [private registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-create-job-private) and then access the referenced image from your job run.

If you created your job by using the job 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 job to point to a different container image, you must first remove the association of the build from your job. 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.
If you don't have an SSH key on your local machine, refer to [these instructions](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys) for creating a key for VPC. By default, the private key is found at $HOME/.ssh/id_rsa.
2. Add the SSH key in the VPC console under Compute / SSH keys. Make sure to create the key in the same resource group where you are going to create the other resources in this tutorial.







 Set environment variables 

This tutorial comes with sample code to illustrate the different options to provision resources and install or update software in a VPC environment.

It will walk you through example steps on a terminal using the shell, terraform and ansible. You will install these tools in later steps. For the scripts to work, you need to define a set of environment variables.



1. Clone the tutorial [source code repository](https://github.com/IBM-Cloud/vpc-tutorials):

git clone https://github.com/IBM-Cloud/vpc-tutorials.git
2. Define a variable named CHECKOUT_DIR pointing to the source code directory:

cd vpc-tutorials
export CHECKOUT_DIR=$PWD
3. Change to the tutorial directory:

cd $CHECKOUT_DIR/vpc-app-deploy
4. Copy the configuration file:

cp export.template export
5. Edit the export file and set the environment variable values:



* TF_VAR_ibmcloud_api_key is an IBM Cloud API key. You can create one [from the console](https://cloud.ibm.com/iam/apikeys).
* TF_VAR_ssh_key_name is the name of the VPC SSH public key identified in the previous section. This is the public key that will be loaded into the virtual service instances to provide secure SSH access via the private key on your workstation. Use the CLI to verify it exists:
Error 1037: Invalid rewrite rule (failed to evaluate expression) 

A common cause of error 1037 is when the expression of the rewrite rule could not be evaluated. There are several causes for this error, but it can mean that one expression element contained an undefined value when it was evaluated.

For example, you get a 1037 error when using the following URL rewrite dynamic expression and the X-Source header is not included in the request:

http.request.headers["x-source"]



 Resolution 

Make sure that all the elements of your rewrite expression are defined. For example, if you are referring to a header value, ensure the header is set.







 Error 1040: Invalid request rewrite (header modification not allowed) 

A common cause of error 1040 is when you are trying to modify an HTTP header that HTTP Request Header Modification Rules cannot change.



 Resolution 

Make sure you are not trying to modify one of the reserved HTTP request headers.







 Error 1041: Invalid request rewrite (invalid header value) 

A common cause of error 1041 is when the added/modified header value is too long or it contains characters that are not allowed.



 Resolution 



* Use a shorter value or expression to define the header value.
* Remove the characters that are not allowed. See Format of HTTP request header names and values in Developer Docs for more information on the allowed characters.









 Error 1101: Rendering error 

A common cause of error 1101 is when an CIS Edge function throws a runtime JavaScript exception.



 Resolution 

Provide appropriate issues details to Support.







 Error 1102: Rendering error 

A common cause of error 1102 is when an Edge function exceeds a CPU time limit. CPU time is the time spent executing code (for example, loops, parsing JSON, etc). Time spent on network requests (fetching, responding) does not count towards CPU time.



 Resolution 

Contact the developer of your Edge function code to optimize code for a reduction in CPU usage in the active Edge function scripts.







 Error 1200: Cache connection limit 

Error 1200 occurs when there are too many requests queued on the edge that are awaiting process by your origin web server. This limit protects CIS's systems.



 Resolution
* 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 deploying the app with a single CLI command. In this scenario, Code Engine uploads your image to IBM Cloud® Container Registry. To learn more, see [Deploying your app from local source code with the CLI](https://cloud.ibm.com/docs/codeengine?topic=codeengine-app-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 deploy your app.



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 app. Then, after the image is matured, you can update the deployed app to reference the specific image that you want. You can repeat this process as needed.

When you deploy your updated app, the latest version of your referenced container image is downloaded and deployed, unless a tag is specified for the image. If a tag is specified for the image, then the tagged image is used for the deployment.



 Updating your app from the console 

Update the application that you created in [Deploying an application from a public registry from the console](https://cloud.ibm.com/docs/codeengine?topic=codeengine-deploy-appdeploy-app-console) to add an environment variable.



1. Navigate to your application page. One way to navigate to your application page is to



* Locate the [Code Engine Projects page](https://cloud.ibm.com/codeengine/projects).
* Click the name of your project to open the Overview page.
* Click Applications to open a list of your applications. Click the name of your application to open its application page.



2. From the application page, you can view information about the running instances of your application and its revisions, configuration details, and endpoint settings of the app.
Code Engine pulls source code from a Git repository or a local directory, builds it, and then pushes (uploads) the image to a container image registry.

You can use [repositories for your source](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories) and [registries for your container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry) that are public or private. You can also choose to specify registry details with a registry secret for your build output, or you can choose to let Code Engine take care of building the image for you from your source and storing the image in IBM Cloud Container Registry with automatic access.





 Next steps for builds 

When your planning is complete, [build your container image](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image).
)?$ <br>Example:https://resource-manager.bluemix.net/v1/resource_groups/56969d6043e9465c883cb9f7363e78e8 
 updated_at <br>date-time The date and time that this gateway was last updated. 





Table 3. Status codes

 Status Code 

 201 The transit gateway was created successfully. 
 400 An invalid transit gateway template was provided. 
 404 A transit gateway location could not be found for the identifier given in the template, a resource group could not be found for the given resource group identifier, or the default resource group could not be found for the account (if no resource group identifier was supplied). 
 409 The transit gateway could not be created as a transit gateway with the same name already exists. 





 Example Response 

This example response illustrates that the transit gateway was created successfully:

{
"created_at": "2020-03-31T12:08:05Z",
"crn": "crn:[...]",
"global": true,
"id": "ef4dcb1a-fee4-41c7-9e11-9cd99e65c1f4",
"location": "us-south",
"name": "example-gateway",
"resource_group": {
"id": "56969d6043e9465c883cb9f7363e78e8"
},
"status": "pending",
"updated_at": "2020-03-31T12:08:05Z"
}

For more information (including Java, Node, Python and Go examples), see "Creates a Transit Gateway" in the [Transit Gateway API reference](https://cloud.ibm.com/apidocs/transit-gateway?code=javacreate-transit-gateway).









 Creating a transit gateway using Terraform 

Review the following argument references that you can specify for your resource when creating a transit gateway using Terraform:



Table 4.
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>







 Resolution for build source not specified correctly 

The typical reason that this error occurs is that the build source is not located in the root directory of the Git repository, but in a child directory. If the build source does not reside inside the root directory, then specify the location in the build.



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 the --context-dir option to specify the path to the source in the Git repository; for example,

ibmcloud ce build update --name <BUILD_NAME> --context-dir <CONTEXT_DIR>
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>