vania-janet/multiturn-rag-retrieval-data huggingface dataset:
{git_org} The organization on github.com that contains the repo. 
 {git_repo} The repo on github.com to integrate into the toolchain. 
 {iam_api_key} Your IAM API key. 
 {region} The region in which the toolchain resides. For example, us-south. 
 {tool_integration_name} A name for your tool integration. 
 {toolchain_id} The ID of the toolchain to which to add the tool integration. 
 {token} A valid IAM bearer token. 



For more information about each of the Git tool integrations, including additional parameters that you can configure, see the following topics:



* [Configuring Bitbucket](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-bitbucket)
* [Configuring GitHub](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-github)
* [Configuring Git Repos and Issue Tracking](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-grit)
* [Configuring GitLab](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-gitlab)







 Adding the Git tool integration to an existing toolchain with Terraform 

You can add a Git tool integration to any existing toolchain with Terraform.



1. To install the Terraform CLI and configure the IBM Cloud provider plug-in for Terraform, follow the tutorial for [Getting started with Terraform on IBM Cloud](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started).
2. Locate the Terraform file (for example, main.tf) that contains the resource block for the toolchain to which you want to add the Git tool integration.
[DevSecOps associated CI toolchain](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-associated-ci-toolchain.png)

Figure 3. DevSecOps associated CI toolchain

Warning: This might overwrite some of the values that you already entered.





 Step 3: Set up CD tool integrations 

If you already linked to an existing CI toolchain in the Welcome step, the names of application-related repositories that are used in that toolchain are prefilled. Review the repository URLs, and then continue to the next steps.



 Application-related repositories 

If you want to set up your CD toolchain from scratch, configure these repositories during CI toolchain creation, and then use or link to them here.

To fetch the respective URL, go to the CI Pipeline, select the respective tool card. Right-click the tool card, and select Copy link address.



* Inventory: The inventory repository records details of artifacts that are built by the CI and CD pipelines. For example, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-inventory
* Issues: The issues repository records issues that are found while the CI pipeline is running. For example, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-issues.
* Evidence: All raw compliance evidence that belongs to the application is collected here. For example, https://<region>.git.cloud.ibm.com/myorg/my-compliance-ci-evidence.



The toolchain currently supports linking only to existing IBM-hosted Git Repos and Issue Tracking repositories.





 Inventory 

Repository URL: URL of the Inventory Repository configured in your CI Toolchain as captured in the previous step.





 Issues
Use the provided toggles to add or remove the vault integrations that you require as explained in [Managing IBM Cloud secrets](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloud). This documentation gives you information on prerequisites and how to use a list of prescribed secret names that are otherwise known as hints. By using hints in a template, a toolchain can be automatically populated with preconfigured secrets without any need to manually select them from various vault integrations that are attached to the toolchain.

This tutorial uses IBM Secrets Manager as the vault for secrets. You might want to go with the secret management offering that you used during CI or CD toolchain setup.

Zoom

![DevSecOps CC Toolchain secrets options](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-Secrets-selection.png)

Figure 3. DevSecOps secrets options

Use [IBM Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-getting-started) to securely store and apply secrets like API keys, Image Signature, or HashiCorp Vault credentials that are part of your toolchain.

Zoom

![DevSecOps IBM Secrets Manager](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-cc-toolchain-setup-SM.png)

Figure 4. DevSecOps IBM Secrets Manager

Multiple repositories must be configured during the guided setup, as described in the next sections.
Toolchain settings
2. The toolchain's name identifies it in IBM Cloud. If you want to use a different name, change the toolchain's name. Because the toolchain name is used to construct the URL that is used to access your app, make sure to specify a unique name.
3. By default, the toolchain creates the source repo in Git Repos and Issue Tracking. To use a different provider for your Git source repo, such as GitHub or GitLab, select it from the list of available repos.

This toolchain uses tools that are included in the Continuous Delivery service. If an instance of that service isn't already in the selected resource group, it is added automatically with the free Lite plan when you click Create to create the toolchain.







 Configure the App repo 



1. In the Git Repos and Issue Tracking tab, review the default setting that specifies the location of your app's source code.
2. By default, the toolchain uses a sample Maven-based Java Hello World app. You can update the location setting to link to your own app instead.

Zoom

![App repo](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/create_toolchain_app_git_repo_updated.png)

Figure 3. App repo







 Configure the Inventory repo 

The Inventory Repository stores the metadata for builds and artifacts. To trigger the pipeline to deploy the artifacts that are described in the commit to the Virtual Server Instance, commit to the Inventory Repository, and then run the acceptance tasks.

Zoom

!
For branch name, enter config-sample-prod.
4. For path, enter deployments/.yaml.
5. Select a cluster group or groups to deploy to.
6. Click Next.



7. On the Summary page, confirm that the displayed information is correct and then click Complete.
8. Observe the hello world sample version 1.0 being deployed to the clusters. You can click the configuration name to see the rollout status. This sample creates a Hello world app in the satellite-config-sample namespace, which serves a simple web page with the current version of the app. Browse to the route of the app to see Hello world 1.0!. You can get the URL of the app from the OpenShift web console or by using the following command.

oc get routes helloworld-route -n satellite-config-sample -o go-template --template='http://{{.spec.host}}{{.spec.path}}{{println}}'.
9. In GitHub, create a pull request from branch config-sample-dev to config-sample-prod.
10. Merge the pull request created in the previous step.
11. In a few minutes, observe the hello world sample version 1.1 being deployed to the clusters.
<-- </section "class="ph" id="section-target-delete-api-cos" "> --><-- <section "class="ph" id="section-target-validate-api-cos" "> --> Validating a target using the API You can use the following cURL command to validate a target by checking the credentials to write to the target. curl -X POST <ENDPOINT>/api/v2/targets/<TARGET_ID>/validate -H "Authorization: $ACCESS_TOKEN" -H "content-type: application/json"
Where<-- <ul> --> * <ENDPOINT> is the API endpoint in the region where you plan to configure or manage a target. For more information, see Endpoints]Endpoints 1] ! ! ! ! . * <TARGET_ID> is the ID of the target.<-- </ul> -->For example, you can use the following cURL request to validate a target in US-South with the ID 00000000-0000-0000-0000-000000000000: curl -X POST https://private.us-south.atracker.cloud.ibm.com/api/v2/targets/<TARGETID>/validate -H "Authorization: $ACCESS_TOKEN" -H "content-type: application/json"
In the response, you get information in the section cos_write_status, for example: "write_status": {
"status": "success"
},
<-- </section "class="ph" id="section-target-validate-api-cos" "> --><-- <section "class="ph" id="section-target-view-api-cos" "> --> Viewing a target using the API You can use the following cURL command to view the configuration details of 1 target: curl -X GET <ENDPOINT>/api/v2/targets/<TARGET_ID> -H "Authorization: $ACCESS_TOKEN" -H "content-type: application/json"
Configuring Bitbucket 

Store your source code in a new or existing repository (repo) on bitbucket.org and engage in social coding through wikis, issue tracking, and pull requests.

Configure Bitbucket to collaborate on code with your team:



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg) and select DevOps. On the Toolchains page, click the toolchain that you want to add Bitbucket to. Alternatively, on the app's Overview page, on the Continuous delivery card, click View toolchain. Then, click Overview.

a. Click Add tool.

b. In the Tool Integrations section, click Bitbucket.

If you are configuring this tool integration on IBM Cloud Public and you did not authorize IBM Cloud to access Bitbucket, click Authorize to go to the Bitbucket website. If you don't have an active Bitbucket session, you are prompted to log in. Click Grant access to allow IBM Cloud Toolchains to access the following parts of your Bitbucket account:



* Read your account information. Get basic user information to populate the user interface.
* Read and modify your repositories' issues. Allow Continuous Delivery to update issues to indicate when the pipeline deploys commits that are attached to those issues.
* Read your team's project settings and read repositories that are contained within your team's projects. Allow Continuous Delivery to integrate with repos that are owned by teams.
* Read and modify your repositories and their pull requests. Allow Continuous Delivery to push sample code into repos, when users request the code.
* Administer your repositories. Allow Continuous Delivery to create new repos, when requested by users.
* Read your team membership information.
Configuring GitLab 

GitLab is a web-based hosting service for Git repos. You can have both local and remote copies of your repos, which makes it easy to collaborate.

You can configure GitLab as a tool integration in your toolchain so that you can manage source code in a new or existing repo on GitLab.com or your company's GitLab instance. Engage in social coding through wikis, issue tracking, and merge requests.

If you are configuring this tool integration as you are creating the toolchain, follow these steps:



1. If you are storing your source code in a GitLab repo, in the Configurable Integrations section, click GitLab. If you are configuring this tool integration on IBM Cloud Public, you must authorize IBM Cloud to access GitLab by choosing either OAuth or Personal Access Token.



* If you choose OAuth, click Authorize to go to the GitLab website. If you don't have an active GitLab session, you are prompted to log in. Click Authorize Application to allow IBM Cloud to access your GitLab account. If you have an active GitLab session but you didn't enter your password recently, you might be prompted to enter your GitLab password to confirm.
* If you choose Personal Access Token, you must enter the personal access token to use to authorize with GitLab to clone repos and perform other actions on your behalf. If you don't have a personal access token, you can follow the documentation on the GitLab website to create one. Make sure that your personal access token has api rights.



2. If you are using a repo on your own GitLab server, in the Configurable Integrations section, click Add custom server.

a. Type a title for your custom GitHub server, specify the root URL for the server, and enter your personal access token.

b. If you don't have a personal access token, you can follow the documentation on the GitLab website to create one.
3.
If the API key is valid and has sufficient access, the schematic workspace, Git repos, and resource group are automatically populated. You can change any of these fields to match your configuration if needed.

Configure the target schematic workspace where the terraform states are maintained:



* Schematic workspace name: The name of the schematic workspace.



* Default: toolchainName-toolchainId-pipelineID









 Signing 

Any code that is built by this toolchain and recorded in the inventory must be signed before the code is delivered to production environment.

To enable signing, provide a GPG key. You can select an existing key from a secret store or input the value directly. Alternatively you can create a new GPG key by clicking NEW.

Ensure that the key follows the appropriate encoding as required by the chosen tool to store secrets.

DevSecOps for IaC creates a detached signature file for the tar.gz file that is created containing the Terraform configuration.

You can also sign the Git release tag that is created by using this GPG key. Add the GPG public key to the Git user profile to verify the signed commits. Use gpg --armor --output <public key file> --export <Email Address> to get the public key content if the gpg --list-keys shows the appropriate GPG key entry.





 Optional tools 



 Slack 

Configure [Slack](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-slack) to receive notifications about your PR or CI pipeline events:



* [Slack webhook](https://api.slack.com/incoming-webhooks)
* Preferred: Import an existing webhook from a secrets vault by clicking the Key icon.
* Copy and paste an existing webhook.
* Slack channel: an existing Slack channel to post messages to.
* Slack team name: the phrase before .slack.com in our team URL. For example, if your team URL [https://team.slack.com](https://team.slack.com), the team name is team.
* [Running a single build with the CLI (with private repo source and and user-provided access to registry)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalonebuildsa-private-cli-b)



* [Running a single build that pulls source from a local directory](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalonebuildsa-local)



* [Running a single build with the CLI (with local source and automatic access to registry)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalonebuildsa-local-cli-a)
* [Running a single build with the CLI (with local source and user-provided access to registry)](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalonebuildsa-local-cli-b)



* [Next steps for builds](https://cloud.ibm.com/docs/codeengine?topic=codeengine-build-standalonenextsteps-buildimage-stand)







 Migrating Cloud Foundry apps to Code Engine 

[Getting started with your migration from Cloud Foundry to Code Engine](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-getstartmigrate-cf-ce-getstart)



* [Migration considerations](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-getstartmigrate-cf-ce-considerations)
* [Next steps](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-getstartmigrate-cf-ce-next)



[Comparing Cloud Foundry and Code Engine terms](https://cloud.ibm.com/docs/codeengine?topic=codeengine-migrate-cf-ce-termsmigrate-cf-ce-terms)
* Read your team's project settings and read repositories that are contained within your team's projects. Allow Continuous Delivery to integrate with repos that are owned by teams.
* Read and modify your repositories and their pull requests. Allow Continuous Delivery to push sample code into repos, when users request the code.
* Administer your repositories. Allow Continuous Delivery to create new repos, when requested by users.
* Read your team membership information. Allow Continuous Delivery to show a list of your teams in the Owner menu that is displayed when you create a new repo.
* Read and modify your repositories' webhooks. Allow the pipeline to trigger builds when commits are pushed to a repo.



If you have an active Bitbucket session but you didn't enter your password recently, you might be prompted to enter your Bitbucket password to confirm.
2. Click the Bitbucket server that you want to use.
3. If you have a Bitbucket repo that you want to use, type the URL for the repo. For the repository type, click Existing.
4. If you want to use a new Bitbucket repo, type a name for the repo, type the URL for the repo that you are cloning or forking, and select the repository type:

a. To create an empty repo, click New.

b. To create a copy of a repo, click Clone.

c. To fork a repo so that you can contribute changes through pull requests, click Fork.
5. To create a private repo on the server, select the Make this repository private checkbox.
6. To use Bitbucket Issues for issue tracking, select the Enable Bitbucket Issues checkbox.
7. 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.
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 about tracking code deployments, see [Track where your code is deployed with toolchains](https://www.ibm.com/cloud/blog/announcements/track-code-deployed-toolchains/).
10. Click Create Integration.



After you clone the Git repo, you can remove it from your toolchain.

If you have a toolchain and are adding Git Repos and Issue Tracking to it, follow these steps:



1. From the IBM Cloud console, click the menu icon ![hamburger icon](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/icon_hamburger.svg) and select DevOps. On the Toolchains page, click the toolchain to open its Overview page. Alternatively, on your app's Overview page, on the Continuous delivery card, click View toolchain. Then, click Overview.
2. Click Add tool.
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.
2. Get a description of the package binding.

ibmcloud fn package get --summary valhallaSamples

Example output

package /<namespace_ID>/valhallaSamples
action /<namespace_ID>/valhallaSamples/greeting: Returns a friendly greeting
action /<namespace_ID>/valhallaSamples/wordCount: Count words in a string
action /<namespace_ID>/valhallaSamples/helloWorld: Demonstrates logging facilities
action /<namespace_ID>/valhallaSamples/curl: Curl a host url

Notice that all the actions in the /whisk.system/samples package are available in the valhallaSamples package binding.
3. Invoke an action in the package binding.

ibmcloud fn action invoke --blocking --result valhallaSamples/greeting --param name Odin

Example output

{
"payload": "Hello, Odin from Valhalla!"
}

Notice from the result that the action inherits the place parameter that you set when you created the valhallaSamples package binding.
4. Invoke an action and overwrite the default parameter value.

ibmcloud fn action invoke --blocking --result valhallaSamples/greeting --param name Odin --param place Asgard

Example output

{
"payload": "Hello, Odin from Asgard!"
}

Notice that the place parameter value that is specified with the action invocation overwrites the default value set in the valhallaSamples package binding.







 Adding your own packages 

You can create a package of local code or a clone of any GitHub repository.

Before you begin



* [Install the Cloud Functions plug-in for the IBM Cloud CLI](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-cli_install).
* Create a manifest.yaml or manifest.yml file for your app and store it in the root directory.
Run a build 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. For example, the following buildrun submit command runs a build run that is called helloworld-buildrun2 that builds from the public Git repo https://github.com/IBM/CodeEngine, and stores the image to the us.icr.io/mynamespace/codeengine-helloworld registry by using the myregistry registry secret to access this registry.

ibmcloud ce buildrun submit --name helloworld-buildrun2 --image us.icr.io/mynamespace/codeengine-helloworld --registry-secret myregistry --source https://github.com/IBM/CodeEngine --context-dir /hello



* In this example, the command uses the default dockerfile strategy, and the default medium build size.
* Because the branch name of the repository is not specified with the --commit option, Code Engine automatically uses the default branch of the specified repository, which is main for this Git repo.
* If you are using the --strategy option with the value of dockerfile, then ensure the --dockerfile option is correctly set to the name of the dockerfile. The default value for the --strategy option is Dockerfile.
* 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

Submitting build run 'helloworld-buildrun2'...
Creating image 'us.icr.io/mynamespace/codeengine-helloworld'...
Run 'ibmcloud ce buildrun get -n helloworld-buildrun2' 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.