vania-janet/multiturn-rag-retrieval-data huggingface dataset:
3. In the Tool Integrations section, click Git Repos and Issue Tracking.
4. Select the server that you want to deploy code changes to. After you create the integration, you can edit it to manage the list of servers that you are authorized to work with. Click Manage Authorization to view a list of all of the servers and to delete the token that you provided to authorize with the server.
5. Select a repository type:

a. To create an empty repo, for the repository type, click New and type a repository name.
b. To fork a Git repo so that you can contribute changes through merge requests, for the repository type, click Fork. Type the URL for the source repo.
c. To create a copy of a Git repo, for the repository type, click Clone. Type a new repo name and the URL for the source repo.
d. If you have a Git repo and want to use it, for the repository type, click Existing. Type the URL for the source repo.
6. Your username is automatically selected to assign ownership of this new integration to yourself. After the integration is created, another authorized user can reassign ownership of the integration to themself when they edit it.
7. If you want to create a private repo, select the Make this repository private checkbox.
8. If you want to use Issues for issue tracking, select the Enable Issues checkbox.
9. If you want to track the deployment of code changes by creating tags and comments on commits, and labels and comments on issues that are referenced by the commits, select the Track deployment of code changes checkbox. For more information, see [Track where your code is deployed with toolchains](https://www.ibm.com/cloud/blog/announcements/track-code-deployed-toolchains/).
10. Click Create Integration.
11. From your toolchain's Overview page, on the Repositories card, click the Git repo that you want to work with. Your project overview page opens.
![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Define your pricing information Choose your pricing plan: free or BYOL. If you choose BYOL, provide details about your license. IBM Cloud console 



For more information, see the following links:



* [Defining your catalog entry and product page](https://cloud.ibm.com/docs/sell?topic=sell-sw-catalog-details)
* [Defining your support experience](https://cloud.ibm.com/docs/sell?topic=sell-sw-support-details)







 Onboard your product 

The following tasks are typically completed by a technical member of your team.



Table 3. Tasks for onboarding software

 Task Description Environment 

 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Set up your source code repository Create a release in your source code repository to deliver and manage versions of your software. Your GitHub or GitLab repository 
 ![Checkbox icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/checkbox-icon.svg) Upload a readme file Provide a readme file that describes how users can install your software and get customer support. Your GitHub or GitLab repository 
 !
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? See the [application create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-application-create) and the [job create](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-create) commands.

Want to learn more about applications and jobs? See [Working with apps in Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-application-workloads) and [Working with jobs and jobruns](https://cloud.ibm.com/docs/codeengine?topic=codeengine-job-plan).





 Clean up
* Define a build configuration from which you can run multiple build runs. See [Building a container image by using a build configuration](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-image).



After your build is complete and your image exists, you can deploy the container image as an application or create a job that references your image.

Let's learn about how to build your container image with a single command and not reference a build configuration. In this scenario, IBM Cloud® Code Engine pulls source code from a Git repository or a local directory, builds it, and then pushes (uploads) the container image to a registry. You can choose public or private [repositories](https://cloud.ibm.com/docs/codeengine?topic=codeengine-code-repositories) and [registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registry). You can choose to specify registry details with a registry secret for your build output with user-provided access. 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.

Consider the following points before you build your container image:



* Before you start building images, review [planning information](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build). You'll also need to verify that you can access the registry. See [Setting up authorities for container registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).
* If you build multiple versions of the same container image, the latest version of the container image is downloaded and used when you run your job or deploy your application, unless a tag is specified for the image. If a tag is specified for the image, then the tagged image is used for the app or job.
* Build runs that are submitted with the CLI that do not reference a defined build configuration are not viewable from the console.
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 Dockerfile not found during build 

A Docker build needs a Dockerfile that specifies how the container image is to be built. If the source repository does not contain such a file, then you need to provide this file or consider buildpacks as a build strategy. For more information, see [Planning your build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-plan-build).



1. If the Dockerfile exists, but has a different name or is not in the root directory, then additional settings need to be specified in the build.



* If the Dockerfile is not in the root directory of the source repository, then you must specify the --context-dir argument and provide the path to the directory that contains the Dockerfile.
* If the Dockerfile is named something other than Dockerfile, then you must specify the --dockerfile argument and provide the name of your Dockerfile.



2. Update the build to use the --context-dir or --dockerfile options as needed.

a. 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 or --dockerfile options as needed; for example,

ibmcloud ce build update --name <BUILD_NAME> [--context-dir <CONTEXT_DIR>] [--dockerfile <DOCKERFILE_NAME>]

b.
LogDNA Target CRN: crn:v1:bluemix:public:logdna:eu-de:a/11111111111111111111111111111111:22222222-2222-2222-2222-222222222222::
CreatedAt: 2022-05-06T18:59:26.760Z
UpdatedAt: 2022-05-06T19:16:50.090Z







 Deleting a target using the CLI 

Use this command to delete a target.

ibmcloud atracker target rm --target TARGET [--force]



 Command options 

--target TARGET
: The ID or name of the target.

--force | -f
: Will delete the target without providing the user with any additional prompt.

help | --help | -h
: List options available for the command.





 Example 

The following is an example using the ibmcloud atracker target rm --target xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx command.

Are you sure you want to remove the target with target ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx? [y/N]>y
OK
Target with target ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx was successfully removed.

The following is an example using the ibmcloud atracker target rm --target xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -force command.

This example shows a failed command where the specified target could not be found.

Are you sure you want to remove the Target bearing Target ID 33333333-3333-3333-3333-333333333333? [y/N]> y
FAILED
Something went wrong. Error:
Status Code: 404
Incident ID: 67a33257-d5a4-46ec-94d9-14eb70e94f3d
Code: not_found
Complete True 2m40s 2m40s

Events:
Type Reason Age Source Messages
Normal Updated 2m41s (x3 over 2m45s) batch-job-controller Updated JobRun "myjobrun-local"
Normal Completed 2m41s batch-job-controller JobRun completed successfully

Instances:
Name Running Status Restarts Age
myjobrun-local-0-0 0/1 Succeeded 0 2m45s



Now that your job is created and run from from repository source code, you can update the job to meet your needs by using the [ibmcloud ce job update](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-job-update) command. For more information about updating jobs, see [Updating a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-update-job). If you want to update your source to use with your job, you must provide the --build-source option on the job update command.

When your job is created from local source or from [repository source code](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job-source-code) with 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.



 Next steps 



* After you create your job, submit the job to run it. See [Run a job](https://cloud.ibm.com/docs/codeengine?topic=codeengine-run-job). You can run your job multiple times.
Use the [ibmcloud ce secret create --format](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command; for example,

ibmcloud ce secret create --format registry --name <REGISTRY_SECRET> --server <REGISTRY_SERVER> --username <USERNAME> --password <PASSWORD>
6. Update the build to reference the name of your registry secret.

a. 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 name of your registry secret; for example,

ibmcloud ce build update --name <BUILD_NAME> --registry-secret <REGISTRY_SECRET>

b. 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>







 Resolution for Dockerfile not found during build 

A Docker build needs a Dockerfile that specifies how the container image is to be built. If the source repository does not contain such a file, then you need to provide this file or consider buildpacks as a build strategy.
ID: abcdefgh-abcd-abcd-abcd-1a2b3c4d5e6f
Project Name: myproject
Project ID: 01234567-abcd-abcd-abcd-abcdabcd1111
Age: 2d15h
Created: 2022-05-24T09:58:43-05:00
Build Type: git
Status: Succeeded
Reason: all validations succeeded

Image: private.us.icr.io/ce--e97a8-odof2whblw5/build-helloworld-build
Registry Secret: ce-auto-icr-private-us-south
Build Strategy: dockerfile-medium
Timeout: 10m0s
Source: https://github.com/IBM/CodeEngine
Commit: main
Context Directory: /hello
Dockerfile: Dockerfile
3. After you create the build, you must [run the build](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-imagebuild-run).







 Creating a build configuration with the CLI (with public repo source and user-provided access to registry) 

In this scenario, Code Engine builds an image from your public Git repository source, and then uploads the image to your container registry with the registry access that you provide.

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).





1. Create a build configuration to build an image from a public Git repo and specify the location of the image registry for the build output with a registry secret.
4. Verify that you're assigned the correct access. You need the following IBM Cloud Identity and Access Management (IAM) roles:



* Administrator on all account management services and all IAM services
* Editor on the Catalog management service
* Manager service access role for IBM Cloud® Schematics
* Other roles that are required for specific resources in your customized deployable architecture









 Importing a version by using the console 



1. Go to Manage > Catalogs > Private catalogs in the IBM Cloud console.
2. Select the private catalog where you want to add your product, and click Add. If you do not have any private catalogs, click Create to add one.
3. Select Deployable architecture as the type of the product that you're adding.
4. Choose Terraform as your delivery method.
5. Select the type of repository. If the source for your deployable architecture is located in a private repository, you need to authenticate with a personal access token.
6. Enter the source URL. This source URL ends in tar.gz and must point to the release snapshot for the version that you're importing.
7. If you created multiple variations of the customized deployable architecture, select the variation you'd like to import first. Variations are used to provide different options within your single catalog tile. For example, a single deployable architecture might have proof of concept and production workload variations as options for users to choose from when deploying.
8. Enter the software version in the format of major version, minor version, and revision, for example, 1.0.0. Typically, this version matches the version number of your release snapshot.

If there are multiple variations for a single deployable architecture, ensure that you're using the same version for all variations. This way all variations appear as options on the tile in the catalog.
9. Select a category. The following two categories are commonly used for deployable architectures: Converged infrastructure and Enterprise applications. If you included a category in your catalog manifest file, it is automatically imported.
10. Click Add product.
11.
{"level":"error","ts":1625217529.587297,"logger":"git","msg":"program failed with an error","error":"fatal: could not read Username for 'https://github.com': terminal prompts disabled (exit code 128)","stacktrace":"main.Executentgithub.com/shipwright-io/build/cmd/git/main.go:100nmain.checkAndRunntgithub.com/shipwright-io/build/cmd/git/main.go:90nmain.mainntgithub.com/shipwright-io/build/cmd/git/main.go:70nruntime.mainntruntime/proc.go:204"}
[...]

The error text is different based on what went wrong. The following table describes error text and potential root causes for this scenario.



Error text and root cases for Git source failed step.

 Error message contains Potential root causes 

 terminal prompts disabled <br><br> * The repository does not exist.<br> * The source URL was provided by using HTTPS protocol, but the repository is private and therefore requires the SSH protocol. The wrong protocol was used.<br><br><br> 
 Host key verification failed <br><br> * The source URL was provided by using SSH protocol, but no secret was provided. The wrong protocol was used or a secret is missing or incorrect.<br><br><br> 
 Permission denied (publickey) <br><br> * The source URL was provided by using SSH protocol, but a secret is missing or incorrect.<br><br><br> 
 Couldn't find remote ref <br><br> * The revision (branch name, tag name, commit ID) specified in the build does not exist.<br><br><br> 



 How to fix it 

Try using the following information to resolve your problem.

Whether you are running your build in the console or in the CLI, use the CLI for troubleshooting problems with your build.
Name Description and resources Code 

 ibm-schematics Retrieve the Terraform on IBM Cloud state file and output variables for a Schematics workspace by using a Schematics data source. For more information, about how to use the data source, see [Managing cross-workspace state access with Terraform on IBM Cloud](https://cloud.ibm.com/docs/schematics?topic=schematics-remote-state). <br> <br>Resources <br><br><br><br> * N/A<br><br><br> [View code snippet](https://github.com/IBM-Cloud/terraform-provider-ibm/tree/master/examples/ibm-schematics) 







 VPC infrastructure templates (Gen 2 compute) 



 Name Description and resources Code 

 ibm-is-ng Create a Virtual Private Cloud (VPC) for Generation 2 compute, configure a VPC load balancer with custom routing rules. Then, add a virtual server instance to your VPC that you can access from the internet by using a public IP address. Then, create another VPC Gen 2 and configure it with a VPN gateway with custom IPsec and IKE networking rules. You also learn how to create VPC Gen 2 block storage volumes.
At minimum, your configuration should consist of a required index document for visitors to view by default, usually written in HTML and named index.html. An optional error document can help your visitors stay on track when they stray. Of course, you can always try for yourself using [this tutorial](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-static-website-tutorial).





 Advanced Configuration 

When you create and configure a new hosted static website, you may also wish to use IBM Cloud Internet Services to configure more advanced options including [routing rules for your domain](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-routing-rules-cos). But you don't even have to go further than configuring your bucket during creation to start customizing your new site.

Zoom

![Configure options](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/cos-sw-ui-complete-config.jpg)

Figure 1. Initial configuration options



 Routing 

Routing gives you control over the requests coming from your visitors. For example, you could globally redirect all of your traffic from using one protocol to another, like replacing HTTP with the secure HTTPS. Or, you can create individual rules that process incoming requests for specific files and provide responses to your visitors based on the rules you define.

Zoom

![Global routing rule](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/cos-sw-ui-global-routing.jpg)

Figure 2. Global routing rule
This command automatically builds and pushes the image to a Container Registry namespace in your account. If you do not have an existing Container Registry namespace, Code Engine automatically creates one for you. For example, the following buildrun submit command runs a build run that is called buildrun-local-dockerfile that builds from the local source.

ibmcloud ce buildrun submit --name buildrun-local-dockerfile --source .

The . indicates the build source is located in your current working directory.



* This example command uses the default dockerfile strategy, and the default medium build size.
* By not specifying the location of the image registry or a registry secret, Code Engine pushes the build output to IBM Cloud Container Registry with automatic access.
* Code Engine automatically determines whether your source resides in a repo or on a local workstation, based on the value of the --source option.



Example output

Packaging files to upload from source path '.'...
Submitting build run 'buildrun-local-dockerfile'...
Creating image 'private.us.icr.io/ce--27fe9-glxo4k7nj7d/buildrun-buildrun-local-dockerfile'...
Run 'ibmcloud ce buildrun get -n buildrun-local-dockerfile' to check the build run status.
OK

The following table summarizes the options that are used with the buildrun submit command in this example. For more information about the command and its options, see the [ibmcloud ce buildrun submit](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-buildrun-submit) command.



Table 5. Command description

 Option Description 

 --name The name of the build run. Use a name that is unique within the project.