vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To learn more about SonarQube, see [SonarQube Documentation](https://docs.sonarqube.org/latest/).





 Using your own configuration file 

You can modify the default configuration without using your own SonarQube instance. Create a sonar-project.properties file in the repo that you want to created the configuration file in. If our script detects an existing configuration sonar-project.properties file in the repo, it uses that file instead of the default file. For more information about possible analysis parameters in the configuration file, see [Analysis Parameters](https://docs.sonarqube.org/latest/analysis/analysis-parameters/) here.

Make sure that you add the correct login credentials and host URL to the configuration file.





 Using another static scan implementation 

You can modify your .pipeline-config.yaml file to add your own custom script to the static-scan stage to use your own static scan implementation.







 Configuring SonarQube by using the API 

The SonarQube tool integration supports the following configuration parameters that you can use with the [Toolchain HTTP API and SDKs](https://cloud.ibm.com/apidocs/toolchain) when you [create](https://cloud.ibm.com/apidocs/toolchaincreate-tool), [read](https://cloud.ibm.com/apidocs/toolchainget-tool-by-id), and [update](https://cloud.ibm.com/apidocs/toolchainupdate-tool) tool integrations.

You must specify the tool_type_id property in the request body with the sonarqube value.



Table 1. SonarQube tool integration parameters

 Parameter Usage Type Terraform argument Description 

 blind_connection optional, updatable, Default: false Boolean blind_connection Set to true to instruct Continuous Delivery to ignore the configuration validation of this integration. Also, set to true if the SonarQube server is not addressable on the public internet. 
 dashboard_url required, updatable String server_url The URL of the SonarQube server dashboars for this tool integration.
Setting up Terraform for Continuous Delivery 

Terraform on IBM Cloud® enables predictable and consistent creation of IBM Cloud services so that you can rapidly build complex, multitier cloud environments by following Infrastructure as Code (IaC) principles. Similar to using the IBM Cloud CLI or API and SDKs, you can automate the creation, update, and deletion of your IBM Cloud® Continuous Delivery instances by using the HashiCorp Configuration Language (HCL).

Looking for a managed Terraform on IBM Cloud® solution? Try out [IBM Cloud® Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started). With Schematics, you can use the Terraform scripting language that you are familiar with without worrying about setting up and maintaining the Terraform command line and the IBM Cloud® Provider plug-in. Schematics also provides pre-defined Terraform templates that you can easily install from the IBM Cloud® catalog.



 Installing Terraform and configuring resources for Continuous Delivery 

Before you begin, make sure that you have the [required access](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd-iam-security) to create and work with continuous-delivery resources, and the [required access](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains-iam-security) to create and work with toolchain resources.



1. Follow the [Terraform on IBM Cloud getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) to install the Terraform CLI and configure the IBM Cloud Provider plug-in for Terraform. The plug-in abstracts the IBM Cloud APIs that are used to create, update, or delete continuous-delivery service instances and toolchain resources.
2. Create a Terraform configuration file that is named main.tf.
"github.com/IBM/ibm-cos-sdk-go/aws/session"
"github.com/IBM/ibm-cos-sdk-go/service/s3"
)







 Creating a client and sourcing credentials 

To connect to IBM Cloud Object Storage, a client is created and configured by providing credential information (API key and service instance ID). These values can also be automatically sourced from a credentials file or from environment variables.

The credentials can be found by creating a [Service Credential](https://cloud.ibm.com/docs/cloud-object-storage/iam?topic=cloud-object-storage-service-credentials), or through the CLI.

Figure 1 shows an example of how to define environment variables in an application runtime at the IBM Cloud Object Storage portal. The required variables are IBM_API_KEY_ID containing your Service Credential 'apikey', IBM_SERVICE_INSTANCE_ID holding the 'resource_instance_id' also from your Service Credential, and an IBM_AUTH_ENDPOINT with a value appropriate to your account, like https://iam.cloud.ibm.com/identity/token. If using environment variables to define your application credentials, use WithCredentials(ibmiam.NewEnvCredentials(aws.NewConfig()))., replacing the similar method used in the configuration example.

![environment variables](https://cloud.ibm.com/docs-content/v1/content/63322f2f3a72050206eb05ba7f590fdcb741105c/cloud-object-storage/images/go-library-fig-1-env-vars.png)



 Initializing configuration 

// Constants for IBM COS values
const (
apiKey = "<API_KEY>" // eg "0viPHOY7LbLNa9eLftrtHPpTjoGv6hbLD1QalRXikliJ"
For a five node ordering service, these nodes will be distributed into multiple zones by default, depending on the relative space available in each zone. You also have the ability to distribute a five node ordering service yourself by clearing the default option to have the zones that are chosen for you and distributing these nodes into the zones you have available. You can check which zone a node was deployed to by opening the tile of the node and looking under the Node location. Alternatively, you can use the APIs to deploy an ordering node to a specific zone. For more information on how to do this with the APIs, see [Creating a node within a specific zone](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-apisibp-v2-apis-zone).

If multizone-capable storage is configured for your Kubernetes cluster when a zone failure occurs, the nodes can come up in another zone, with their associated storage intact, ensuring high availability of the node. In order to leverage this capability with the IBM Blockchain Platform, you need to configure your cluster to use SDS (Portworx) storage. And when you deploy an ordering service or an ordering node, select the advanced deployment option labeled Deployment zone selection and then select Across all zones. To learn more about multizone-capable storage, see the Comparison of persistent storage options for multizone clusters on [OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_planningpersistent_storage_overview) or [IBM Cloud Kubernetes service](https://cloud.ibm.com/docs/containers?topic=containers-storage_planningpersistent_storage_overview).





 Sizing an ordering node during creation 

Because ordering nodes do not maintain a copy of the state DB, they require fewer containers than peers do. However, they do host the blockchain (the transaction history) because the blockchain is where the channel configuration is stored, and the ordering service must know the latest channel configuration to perform its role.
// Constants for IBM COS values
SDKGlobalConfiguration.IAM_ENDPOINT = "https://iam.cloud.ibm.com/oidc/token";
api_key = "<api-key>"; // example: xxxd12V2QHXbjaM99G9tWyYDgF_0gYdlQ8aWALIQxXx4
service_instance_id = "<resource-instance-id>"; // example: crn:v1:bluemix:public:cloud-object-storage:global:a/xx999cd94a0dda86fd8eff3191349999:9999b05b-x999-4917-xxxx-9d5b326a1111::
endpoint_url = "<endpoint>"; // example: https://s3.us-south.cloud-object-storage.appdomain.cloud
location = "<storage-class>"; // example: us-south-standard

// Create client connection details
_cosClient = createClient(api_key, service_instance_id, endpoint_url, location);

// Setting string values
String bucketName = "java.bucket" + UUID.randomUUID().toString().replace("-","");
String itemName = UUID.randomUUID().toString().replace("-","") + "_java_file.txt";
String fileText = "This is a test file from the Java code sample!!!";

// create a new bucket
createBucket(bucketName, _cosClient);

// get the list of buckets
listBuckets(_cosClient);

// create a new text file & upload
createTextFile(bucketName, itemName, fileText);

// get the list of files from the new bucket
listObjects(bucketName, _cosClient);
import com.ibm.cloud.objectstorage.services.s3.model.ListObjectsRequest;
import com.ibm.cloud.objectstorage.services.s3.model.ObjectListing;
import com.ibm.cloud.objectstorage.services.s3.model.S3ObjectSummary;
import com.ibm.cloud.objectstorage.oauth.BasicIBMOAuthCredentials;

public class App
{
private static AmazonS3 _cosClient;

/
* @param args
/
public static void main(String[] args)
{
SDKGlobalConfiguration.IAM_ENDPOINT = "https://iam.cloud.ibm.com/identity/token";
String bucketName = "<sample-bucket-name>";
String api_key = "ZRZDoNoUseOLL7bRO8SAMPLEHPUzUL_-fsampleyYE";
String service_instance_id = "85SAMPLE-eDOb-4NOT-bUSE-86nnnb31eaxx"
String endpoint_url = "https://s3.us-south.cloud-object-storage.appdomain.cloud";
String storageClass = "us-south";
String location = "us";

_cosClient = createClient(api_key, service_instance_id, endpoint_url, location);

// Define a rule for expiring items in a bucket
int days_to_delete = 10;
BucketLifecycleConfiguration.Rule rule = new BucketLifecycleConfiguration.Rule()
.withId("Delete rule")
.withExpirationInDays(days_to_delete)
.withStatus(BucketLifecycleConfiguration.ENABLED);

rule.setFilter(new LifecycleFilter());

// Add the rule to a new BucketLifecycleConfiguration.
BucketLifecycleConfiguration configuration = new BucketLifecycleConfiguration()
Project CLI reference 

The IBM Cloud® command-line interface (CLI) provides extra capabilities for service offerings. You can use the IBM Cloud CLI to manage projects you have access to.



 Before you begin 



* Install the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started).
* Install the Project CLI by running the following command:

ibmcloud plugin install project



You're notified on the command line when updates to the IBM Cloud CLI and plug-ins are available. Be sure to keep your CLI up to date so that you can use the latest commands. You can view the current version of all installed plug-ins by running ibmcloud plugin list.

IBM Cloud CLI requires Java™ 1.8.0.





 ibmcloud project create 

Create a new project and asynchronously setup the tools to manage it. Add a deployable architecture by customizing the configuration. After the changes are validated and approved, deploy the resources that the project configures.

ibmcloud project create --resource-group RESOURCE-GROUP --location LOCATION --name NAME [--description DESCRIPTION] [--destroy-on-delete DESTROY-ON-DELETE] [--configs CONFIGS]



 Command options 

--resource-group (string)
: The resource group where the project's data and tools are created. Required.

The maximum length is 40 characters. The minimum length is 0 characters. The value must match regular expression /^$|^(?!\s)(?!.\s$)[ !!] ! ^'"<>{}\x00-\x1F]*$/\.
--location (string): The location where the project's data and tools are created. Required.
The maximum length is 12 characters. The minimum length is 0 characters. The value must match regular expression /^$|^(us-south|us-east|eu-gb|eu-de)$/.
Ordering and configuring IBM Cloud Object Storage with Veeam 

Veeam® is compatible with IBM Cloud® Object Storage. IBM Cloud Object Storage is not automatically ordered when you order Veeam, but you can add it after deployment.

To order IBM Cloud Object Storage, complete the following tasks in the specified order.



 Creating an Object Storage instance 

For more information about creating an Object Storage instance, see [Creating a new service instance](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-provisionprovision-instance). Follow the steps and return here to continue with the following tasks.





 Creating a bucket 

For more information about creating a bucket, see [Create some buckets to store your data](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storagegs-create-buckets). Follow the steps and return here to continue with the following tasks.





 Creating service credentials 

For more information about creating service credentials, see [Service credentials](https://cloud.ibm.com/docs/cloud-object-storage/hmac?topic=cloud-object-storage-service-credentials). Follow the steps and return here to continue with the following tasks.





 Adding a scale-out repository 



* As part of the Veeam service installation and configuration, a scale-out backup repository with the name IC4V Scale-Out Repository is created. The IC4V Default VM Backup Repository repository is added to the scale-out repository as an extent.
* When you create the backup job, you must select IC4V Scale-Out Repository as the backup repository, and not IC4V Default Config Backup Repository. The latter repository is intended for the Veeam configuration backups.
* You can add more repositories to this default repository, such as a backup repository of type Object Storage. For more information, see [Adding scale-Out repositories](https://helpcenter.veeam.com/docs/backup/vsphere/sobr_add.html?ver=95u4).
If you manually built your organization MSP with certificates from an external CA, the connection profile will not include any information in the "certificateAuthorities": section.





 Service discovery 

Service discovery allows your applications to dynamically find the peer and ordering endpoints of your network. If you do not use service discovery, you need to manually add the endpoint information of peer and ordering nodes on your channel to your connection profile or your application. You would need to edit your connection profile or update your application each time a node is added or removed from your network.

Before you can take advantage of the [Service Discovery](https://hyperledger-fabric.readthedocs.io/en/release-2.2/discovery-overview.html) feature of Hyperledger Fabric, you must configure anchor peers on the channel. Service discovery allows your application to learn which peers on the channel outside your organization need to endorse a transaction. Without service discovery, you will need to get the endpoint information of these peers out of band from other organizations and add them to your connection profile. For more information, see [Configuring anchor peers](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-governibp-console-govern-channels-anchor-peers).

Later in this topic, we use the connection profile to build a Fabric gateway that is configured for [service discovery](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-appibp-console-app-sd-cfg).





 Enrolling by using the SDK 

Once the network operator provides the enroll ID and secret of the application identity and the network connection profile, an application developer can use the Fabric SDKs or the Fabric CA client to generate client-side certificates. You can use the following steps to enroll an application identity by using the [Fabric SDK for Node.js](https://hyperledger.github.io/fabric-sdk-node/release-2.2/index.html).



1. Save the connection profile to your local system and rename it connection.json.
2.
Building and deploying 

IBM Cloud® Continuous Delivery includes Delivery Pipeline, which you can use to implement a repeatable continuous integration and continuous delivery process.

Complete the following tasks to configure a pipeline.



 Adding a stage 



1. On the Pipeline page, click ADD STAGE. The Stage Configuration page opens.
2. Configure the stage.

a. On the INPUT tab, select an input for the stage. For Build stages, the input tab includes a Branch field to specify the branch in the repo to use for input.

b. On the JOBS tab, add and configure at least one job. The first stage usually has at least a build job.
3. Click SAVE.







 Adding a job to a stage 



1. On the stage, click the Stage Configuration icon, and then click Configure Stage.
2. Click the JOBS tab.
3. Click ADD JOB. Select the type of job to add.
4. Configure the job.
5. Click SAVE.



Zoom

![Adding a job to a stage](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/AddJob2.png)

Figure 1. Adding a job to a stage





 Running a stage 

You can manually run a stage by clicking the Run Stage icon on the Pipeline page.

Zoom

![Clicking the Run Stage icon on a stage](https://cloud.ibm.com/docs-content/v1/content/562806c0b18119f4d21cb66f5ae6d051634b4a16/ContinuousDelivery/images/RunStage.png)

Figure 2. Running a stage

You can also request on-demand builds and deployments from the build history page in one of two ways:
Configuring the management interfaces 

The IBM Cloud® Juniper vSRX nodes provide built-in management interfaces ("fxp0") that are not configured by default. When configured, these private interfaces can be used to communicate with the individual node, which might be useful in a high availability cluster for monitoring the status of the secondary node over SSH, ping, SNMP, and so on. Since the private IP for the vSRX floats to the primary node, it is not possible to directly access the secondary node.

Configuration of the fxp0 interface requires IPs in a subnet that is attached to the private transit VLAN for the gateway. Although the primary subnet that comes with the gateway has IPs that might be available, it is not recommended for this use. This is because the primary subnet is reserved for the gateway provisioning infrastructure, and IP collisions could occur if additional gateways are deployed in the same pod.

You can allocate a secondary subnet for the private transit VLAN, and use IPs from this subnet to configure fxp0 and the host bridge interface for PING and SSH access. To do so, perform the following procedure:



1. [Order a portable private subnet](https://cloud.ibm.com/classic/network/subnet/provision) and assign it to the vSRX private transit VLAN. You can find the private transit VLAN on the gateway details page.

Ensure the subnet includes at least 8 addresses in order to support 2 IPs for the host bridge interfaces, and 2 IPs for the vSRX fxp0 interfaces.
2. Configure the host br0:0 bridge interfaces using 2 IPs from the new subnet. For example:

On Ubuntu host 0: ifconfig br0:0 10.177.75.140 netmask 255.255.255.248

On Ubuntu host 1: ifconfig br0:0 10.177.75.141 netmask 255.255.255.248
3. Persist the bridge interface configurations across reboots by modifying /etc/network/interfaces on each Ubuntu host. For example:

auto br0:0
grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{Certificates: []tls.Certificate{cert}}))
}

The tls.Config{} needs to be properly defined based on the [Config type struct](https://pkg.go.dev/crypto/tlsConfig). You need to set at least the Certificates field. Make sure to use your client key and client certificate. For the complete Golang example code, see [The sample GitHub repository for Golang](https://github.com/IBM-Cloud/hpcs-grep11-go/blob/master/examples/server_test.go).
* JavaScript example code snippet

credentials.push(grpc.credentials.createSsl());

You can refer to the [Credentials module documentation](https://grpc.github.io/grpc/node/grpc.credentials.html) for detailed information on functions and parameters. You need to set the private_key and cert_chain parameters for createSsl() function. For the complete JavaScript example code, see [The sample GitHub repository for JavaScript](https://github.com/IBM-Cloud/hpcs-grep11-js/blob/master/examples/credentials.js).



* Configure PKCS #11 applications

PKCS #11 handles mutual TLS in its [configuration file](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-pkcs-apistep3-setup-configuration-file). Update the tls field according to the following example:

tls:
enabled: true
mutual: true
cacert:
certfile: "<client_certificate>"
keyfile: "<client_certificate_private_key>"

Replace the variables in the example based on the following table:



Table 3.
Setting up Terraform for subnets 

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud services so that you can rapidly build complex, multi-tier cloud environments following Infrastructure as Code (IaC) principles. Similar to using the IBM Cloud CLI or API and SDKs, you can automate the provisioning, update, and deletion of your subnet resources by using HashiCorp Configuration Language (HCL).

Looking for a managed Terraform on IBM Cloud® solution? Try out [IBM Cloud® Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started). With Schematics, you can use the Terraform scripting language that you are familiar with, but you don't have to worry about setting up and maintaining the Terraform command line and the IBM Cloud® Provider plug-in. Schematics also provides pre-defined Terraform templates that you can easily install from the IBM Cloud® catalog.



 Installing Terraform and configuring resources for subnets 

Before you can create an authorization by using Terraform, make sure that you have completed the following:



* Make sure that you have the [required access](https://cloud.ibm.com/docs/account?topic=account-mngclassicinfra) to create and work with subnet resources.
* Install the Terraform CLI and configure the IBM Cloud Provider plug-in for Terraform. For more information, see 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). The plug-in abstracts the IBM Cloud APIs that are used to complete this task.
* Create a Terraform configuration file that is named main.tf. In this file, you define resources by using HashiCorp Configuration Language. For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).





1. Create a Terraform configuration file that is named main.tf.
For more information about profiles, see [Working with profiles](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-profiles).

Select the IBM Cloud Security Best Practices v1.0.0 profile for DevSecOps toolchains.
6. Click Create Integration.
7. On your Toolchain's Overview page, on the IBM Cloud tools card, click Security and Compliance Center.





 Configuring Security and Compliance Center by using the API 

The Security and Compliance Center tool integration supports the following configuration parameters that you can use with the [Toolchain HTTP API and SDKs](https://cloud.ibm.com/apidocs/toolchain) when you [create](https://cloud.ibm.com/apidocs/toolchaincreate-tool), [read](https://cloud.ibm.com/apidocs/toolchainget-tool-by-id), and [update](https://cloud.ibm.com/apidocs/toolchainupdate-tool) tool integrations.

You must specify the tool_type_id property in the request body with the security_compliance value.



Table 1. Security and Compliance Center tool integration parameters

 Parameter Usage Type Terraform argument Description 

 api-key optional, updatable, deprecated Password api_key Deprecated. The IBM Cloud API key that is used to access the Security and Compliance Center API. This parameter is relevant only when the trigger_scan parameter is enabled. You can use a toolchain secrets reference for this parameter. For more information about secrets references, see [Protecting your sensitive data in Continuous Delivery](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_securitycd_secure_credentials). 
 evidence_namespace required, updatable String evidence_namespace The type of pipeline evidence to display in Security and Compliance Center for this toolchain. Valid values are cd (uses evidence that is generated by a continuous deployment pipeline) or cc (uses evidence that is generated by a continuous compliance pipeline).