vania-janet/multiturn-rag-retrieval-data huggingface dataset:
"after": "af363efb8568874fe219bc73f3bccd0f4991907f",
"repository": {

...

"committer": {
"name": "GitHub",
"email": "noreply@github.com",
"username": "web-flow"
},
"added": [],
"removed": [],
"modified": [
"README.md"
]
}
}
2022/11/28 19:45:28 kersten1 committed "af363efb8568874fe219bc73f3bccd0f4991907f" to "refs/heads/main" branch
2022/11/28 19:45:28 ibmcloud ce buildrun submit ...

Your output is dependent on the application that you use and the GitHub repository that contains the webhook.



Your webhook is working! Now your app receives notification whenever you commit a file to your GitHub repository.

This application sets the minimum scale to 1 so that an instance of the app is always running. You can set the scale to 0 by updating the app with the following command. ibmcloud ce app update --name my-github-app --min-scale 0.





 Clean up 

After you finish this tutorial, you can clean up the resources that you created with the following commands.



1. Delete your application

ibmcloud ce app delete --name my-github-app

When you delete your app, the associated build files are also deleted.
2. Delete the webhook by opening your GitHub settings -> Webhooks and clicking Delete after the webhook name.
3. Delete the images that the build created from IBM Cloud Container Registry.



1. Navigate to [Registry](https://cloud.ibm.com/registry/start) in the IBM Cloud console.
2.
: You can now [set up trusted content for container images](https://cloud.ibm.com/docs/containers?topic=containers-imagestrusted_images) that are signed and stored in IBM Cloud Container Registry.





 1 March 2021 

CLI change log
: Updated the IBM Cloud Kubernetes Service CLI plug-in change log page for the [release of version 1.0.233](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_changelog10).

Istio add-on
: [Version 1.8.3 of the Istio managed add-on](https://cloud.ibm.com/docs/containers?topic=containers-istio-changelog183) is released.

Worker node versions
: Worker node fix pack update change log documentation is available for version [1.20.4_1531](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1201204_1531), [1.19.8_1538](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1191198_1538), [1.18.16_1544](https://cloud.ibm.com/docs/containers?topic=containers-118_changelog11816_1544), and [1.17.17_1555](https://cloud.ibm.com/docs/containers?topic=containers-117_changelog11717_1555_worker).







 February 2021 



 27 February 2021 

Master versions
For more information about private Container Registry networks, see [Securing your connection to Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_private).

For VPE gateways that are created after 11 November 2022, you can pull images from any other Container Registry region by using the public hostnames, such as uk.icr.io.



 Configuring an endpoint gateway 

To configure a VPE gateway, complete the following steps:



1. List the available services, including IBM Cloud infrastructure services available (by default) for all VPC users. For more information, see [VPE supported services](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-supported-services).
2. [Create an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-ordering-endpoint-gateway) for IBM Cloud Container Registry that you want to be privately available to the VPC. To create the VPE gateway by using the CLI, run the following command, where <CRN> is the CRN of the target region as shown in Table 1.

ibmcloud is endpoint-gateway-create --target <CRN> --vpc-id <VPC-ID> --name myname
3. [Bind a reserved IP address](https://cloud.ibm.com/docs/vpc?topic=vpc-bind-unbind-reserved-ip) to the endpoint gateway.
4. View the created VPE gateways associated with the IBM Cloud Container Registry. For more information, see [Viewing details of an endpoint gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-vpe-viewing-details-of-an-endpoint-gateway).



Now your virtual server instances in the VPC can access your IBM Cloud Container Registry instance privately through it.
1. Make sure you are logged in to the IBM Cloud® Container Registry either using the ibmcloud cr login CLI or with your API key docker login -u iamapikey -p <your apikey> icr.io.
2. Deploy the stack.

docker stack deploy --compose-file satellite-connector-agent.yaml --with-registry-auth satellite_connector



2. Verify the Satellite Connector agent service is running.

docker service ps satellite_connector_agent
container-registry 0.1.471
container-service/kubernetes-service 1.0.57
doi 0.2.1

 ibmcloud dev --version
ibmcloud dev version 2.4.8

 java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.20.0, JRE 11 Linux amd64-64-Bit Compressed References 20200416_574 (JIT enabled, AOT enabled)
OpenJ9 - 05fa2d361
OMR - d4365f371
JCL - 838028fc9d based on jdk-11.0.7+10)

 ant -version
Apache Ant(TM) version 1.10.8 compiled on May 10 2020

 mvn -version
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /opt/IBM/maven
Java version: 11.0.7, vendor: Eclipse OpenJ9, runtime: /usr/local/openjdk-11
Default locale: c.u_US, platform encoding: UTF-8
OS name: "linux", version: "4.19.76-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 6.4!

Here are the highlights of this release:
- Support for building, testing and running Java Modules
- Precompiled script plugins for Groovy DSL
- Single dependency lock file per project

For more details see https://docs.gradle.org/6.4/release-notes.html
You can [set up the entitled Helm chart repository](https://cloud.ibm.com/docs/containers?topic=containers-helm), where Helm charts that incorporate entitled software are stored. If you already have Helm installed in your cluster, run helm repo add entitled https://raw.githubusercontent.com/IBM/charts/master/repo/entitled.





 Updating an IBM Cloud Kubernetes Service containerd custom registry configuration 

With Kubernetes version 1.22 or later, you can use containerd configuration files on worker nodes to configure pulling from a container registry. You can use a daemonset to update the configurations across all nodes in a cluster, which prevents configurations from being wiped when worker nodes reload or when new workers are added.



 Example daemonset to update a containerd custom registry configuration 

Use the example YAML file to define a daemonset that runs on all worker nodes to set or update a containerd registry host configuration and mount to the corresponding containerd registry path.

The example sets the following registry host configuration for dockerhub. This registry host configuration is already provided and automatically configured during the worker provisioning phase. The init container initializes hosts.toml on every worker node after deployment and after worker nodes reload or restart.

server = "https://docker.io"
[host."https://registry-1.docker.io"]
capabilities = ["pull", "resolve"]

Example YAML file:

apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
name: containerd-dockerhub-registry-config
name: containerd-dockerhub-registry-config
namespace: kube-system
spec:
selector:
matchLabels:
name: containerd-dockerhub-registry-config
template:
metadata:
labels:
name: containerd-dockerhub-registry-config
spec:
initContainers:
- image: alpine:3.13.6
container-registry 0.1.571 true
container-service[kubernetes-service/ks] 1.0.420 false
cra 0.1.20 false
doi 0.3.8 false
schematics 1.10.0 true

 ibmcloud dev --version
ibmcloud dev version 2.12.0

 java -version
openjdk version "17.0.3" 2022-04-19
IBM Semeru Runtime Open Edition 17.0.3.0 (build 17.0.3+7)
Eclipse OpenJ9 VM 17.0.3.0 (build openj9-0.32.0, JRE 17 Linux amd64-64-Bit Compressed References 20220422_184 (JIT enabled, AOT enabled)
OpenJ9 - 9a84ec34e
OMR - ab24b6666
JCL - dc07fd49b92 based on jdk-17.0.3+7)

 ant -version
Apache Ant(TM) version 1.10.12 compiled on October 13 2021

 mvn -version
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /opt/IBM/maven
Java version: 17.0.3, vendor: IBM Corporation, runtime: /usr/local/jdk17
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.10.104-linuxkit", arch: "amd64", family: "unix"

 gradle -version

Welcome to Gradle 7.4.2!

Here are the highlights of this release:
- Aggregated test and JaCoCo reports
- Marking additional test source directories as tests in IntelliJ
- Support for Adoptium JDKs in Java toolchains

For more details see https://docs.gradle.org/7.4.2/release-notes.html
* [Set up your own private registry in IBM Cloud to store and share Docker images with other users.](https://cloud.ibm.com/docs/Registry?topic=Registry-getting-started)
* [Set up the cluster autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc) to automatically add or remove worker nodes from your worker pools based on your workload resource requests.
* Control who can create pods in your cluster with [pod security policies](https://cloud.ibm.com/docs/containers?topic=containers-psp).
* Enable the [Istio](https://cloud.ibm.com/docs/containers?topic=containers-istio) managed add-on to extend your cluster capabilities.



Then, you can check out the following network configuration steps for your cluster setup:



* Classic clusters:



* Isolate networking workloads to edge worker nodes [in classic clusters without a gateway](https://cloud.ibm.com/docs/containers?topic=containers-edge).
* Expose your apps with [public networking services](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningpublic_access) or [private networking services](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planningprivate_access).
* Connect your cluster with services in private networks outside of your IBM Cloud account by setting up [IBM Cloud Direct Link](https://cloud.ibm.com/docs/dl?topic=dl-get-started-with-ibm-cloud-dl) or the [strongSwan IPSec VPN service](https://cloud.ibm.com/docs/containers?topic=containers-vpn).
container-registry.image.list [ibmcloud cr image-digests](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_digests) List all your container images, including untagged images.<br><br>[ibmcloud cr image-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_list) List your tagged container images.<br><br>[ibmcloud cr image-prune-untagged](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregcliic_cr_image_prune_untagged) Delete all untagged images in your Container Registry account.<br><br>[ibmcloud cr trash-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_trash_list) Display the container images that are in the trash. Reader, Manager 
 container-registry.image.pull docker pull Pull a container image.<br><br>docker trust inspect Inspect the signature for a container image.<br><br>[ibmcloud cr image-tag](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_tag) Create a container image that refers to a source image.<br><br>[ibmcloud cr vulnerability-assessment](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_va) View a vulnerability assessment report for your container image. Reader, Writer, Manager
For more information, see [Deploying apps to specific worker nodes by using labels](https://cloud.ibm.com/docs/containers?topic=containers-deploy_appnode_affinity).

Example for preferred anti-affinity

spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- wasliberty
topologyKey: kubernetes.io/hostname





 Container image 

Specify the image that you want to use for your containers, the location of the image, and the image pull policy. If you don't specify an image tag, by default it pulls the image that is tagged latest.

Avoid using the latest tag for production workloads. You might not have tested your workload with the latest image if you are using a public or shared repository, such as Docker Hub or IBM Cloud Container Registry.

For example, to list the tags of public IBM images:



1. Switch to the global registry region.

ibmcloud cr region-set global
2. List the IBM images.

ibmcloud cr images --include-ibm



The default imagePullPolicy is set to IfNotPresent, which pulls the image only if it does not exist locally. If you want the image to be pulled every time that the container starts, specify the imagePullPolicy: Always.

containers:
- name: wasliberty
image: icr.io/ibm/liberty:webProfile8
imagePullPolicy: Always





 Port for the app's service 

Select a container port to open the app's services on. To see which port needs to be opened, refer to your app specs or Dockerfile. The port is accessible from the private network, but not from a public network connection. To expose the app publicly, you must create a NodePort, load balancer, or Ingress service.
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).
* Before you can work with a Code Engine job that references an image in a private registry, you must first add access to the registry, pull the image, and then create your job configuration.





1. To pull images from a private registry, you must first create a private registry. For example, to create a private Docker Hub registry, see [Docker Hub documentation](https://docs.docker.com/docker-hub/repos/). After you create a private registry, [push an image to it](https://docs.docker.com/docker-hub/repos/pushing-a-docker-container-image-to-docker-hub). You can also set up an access token. By using an access token, you can more easily grant and revoke access to your Docker Hub account without requiring a password change. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).
2. Add access to your private registry to pull images. To add access to a private registry with the CLI, use the [ibmcloud ce secret create --format registry](https://cloud.ibm.com/docs/codeengine?topic=codeengine-clicli-secret-create) command to create an registry secret. For example, the following command creates registry access to a Docker Hub registry called privatedocker that is at https://index.docker.io/v1/ and uses your username and password.

ibmcloud ce secret create --format registry --name privatedocker --server https://index.docker.io/v1/ --username <Docker_User_Name> --password <Password>

Example output

Creating registry secret 'privatedocker'...
OK
3.
4. Note the master_hostname and master_public_ip that was assigned to your master node. To show all your resources with the assigned host names and IP addresses, run terraform show.
5. Exit your container.

exit
6. On your local machine, add the master node as a host to your local /etc/hosts file.



1. Open the /etc/hosts file.

sudo vi /etc/hosts
2. Insert the following line to the end of your file.

<master_public_ip> <master_hostname>



7. Open the OpenShift console.

open https://$(terraform output master_public_ip):8443/console
8. Set up users and authentication for your OpenShift cluster. The OpenShift Container Platform master includes a built-in OAuth server. By default, this OAuth server is set up to deny all authentication. To let developers and administrators authenticate with the cluster, follow the steps in [Configuring access and authentication ![External link icon](https://cloud.ibm.com/docs-content/v1/content/4cd6263f39a034d265ddb4b0a5e6d50c55d13ee8/icons/launch-glyph.svg)](https://docs.openshift.com/container-platform/3.11/install_config/configuring_authentication.htmlinstall-config-configuring-authentication) to set up access for your cluster.
9. Configure your Docker registry. During the creation of your cluster, an internal, integrated Docker registry is automatically set up for you. You can use the registry to build container images from your source code, deploy them, and manage their lifecycle. For more information, see [Registry Overview !
Optional: If you plan to access your data with a non-root user, or added files to an existing IBM Cloud Object Storage bucket by using the console or the API directly, make sure that the [files have the correct permission](https://cloud.ibm.com/docs/containers?topic=containers-cos_nonroot_access) assigned so that your app can successfully read and update the files as needed.
5. To mount the PV to your deployment, create a configuration .yaml file and specify the PVC that binds the PV.

apiVersion: apps/v1
kind: Deployment
metadata:
name: <deployment_name>
labels:
app: <deployment_label>
spec:
selector:
matchLabels:
app: <app_name>
template:
metadata:
labels:
app: <app_name>
spec:
containers:
- image: <image_name>
name: <container_name>
securityContext:
runAsUser: <non_root_user>
volumeMounts:
- name: <volume_name>
mountPath: /<file_path>
volumes:
- name: <volume_name>
persistentVolumeClaim:
claimName: <pvc_name>
Show more



app
: In the metadata section, enter label for the deployment.

matchLabels.app and labels.app
: In the spec selector and in the spec template metadata sections, enter a label for your app.

image
: The name of the container image that you want to use. To list available images in your IBM Cloud Container Registry account, run ibmcloud cr image-list.

name
: The name of the container that you want to deploy to your cluster.

runAsUser
: In the spec containers security context section, you can optionally set the run as user value.

mountPath
: In the spec containers volume mounts section, enter the absolute path of the directory to where the volume is mounted inside the container.
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. Select Container image and click Configure image.
7. Enter docker.io for Registry server.
8. For Registry access secret, select Create registry access secret.
9. From the Create registry access secret page, choose your registry source. For example, Docker Hub.
10. From the Create registry access secret page, enter a username. For Docker Hub, it is your Docker ID.
11. From the Create registry access secret page, enter the password. For Docker Hub, you can use your Docker Hub password or an access token. For more information about access tokens and Docker Hub, see [Managing access tokens](https://docs.docker.com/docker-hub/access-tokens/).
12. Click Create to add the registry access for Code Engine.
13. From the Configure image page, the registry access secret that was added is listed. Select the registry access secret for your image.
14. Select the namespace and name of the image in Docker Hub for the Code Engine job to reference. For example, select mynamespace and select the image testjob in that namespace.
15. Select a value for Tag; for example, latest.
16. Click Done. You selected your image in the registry to reference from your job.
17. 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).
18.
If the image-key-id is not specified, the command first tries to determine the ID automatically by requesting the container registry notary service. You are prompted for this parameter for Docker Hub images.

--fingerprint FINGERPRINT
: If the image is in ICR, the fingerprint of the gpg key that is used to sign the image must be provided. You can get the fingerprint by using the gpg --list-keys name_of_the_key command. For example, when you run the gpg --list-keys latestnewkey command, the following snippet is an example of the output:

pub rsa4096 2023-01-12 [SCEA] [expires: 2024-04-28]
322A65D5B50BF16F5FDB6D7173943217FCD72F51
uid [ultimate] latestnewkey
<latestnewkey@example.com>
sub rsa4096 2023-01-1--fingerprint FINGERPRINT2 [SEA] [expires: 2024-04-28]

In this example, "322A65D5B50BF16F5FDB6D7173943217FCD72F51" is the fingerprint.

--image-key-public-path PUBLIC-KEY
: The path for the file that contains the public part of the key that is used to sign the image. The public part of the key must be a minimum of 20 characters and base64 encoded. If the path is not specified, the command first tries to determine the public part of the key automatically by requesting the container registry notary service. If the image is present in ICR, path to the gpg public key that is used to sign the image should be mandatorily provided. It is optional for DCT signed image in Docker Hub.

--registration-key-public-path PRIVATE-KEY-PATH
: The path for the public key from the registration key pair. You must save these keys in a safe and secure location for future use.

--registration-key-private-path PUBLIC-KEY-PATH
For information about required permissions for accessing image registries, see [Setting up authorities for image registries](https://cloud.ibm.com/docs/codeengine?topic=codeengine-add-registryauthorities-registry).

The following example application create command creates and deploys the myapp app, which references an image that is built from the https://github.com/IBM/CodeEngine build source. This command automatically builds the image and uploads the image to an IBM Cloud® Container Registry namespace in your account and the application references this built image. By specifying the --build-context-dir option, the build uses the source in the helloworld directory. This example command uses the default dockerfile strategy, and the default medium build size. Because the branch name of the repository is not specified with the --build-commit option, Code Engine automatically uses the default branch of the specified repository.

ibmcloud ce application create --name myapp --build-source https://github.com/IBM/CodeEngine --build-context-dir helloworld

Example output

Creating application 'myapp'...
Submitting build run 'myapp-run-220411-13abcdefg'...
Creating image 'private.us.icr.io/ce--abcde-4svg40kna19/app-myapp:220411-1756-if8jv'...
Waiting for build run to complete...
Build run status: 'Running'
Build run completed successfully.
Run 'ibmcloud ce buildrun get -n myapp-run-220411-13abcdefg' to check the build run status.
Waiting for application 'myapp' to become ready.
Configuration 'myapp' is waiting for a Revision to become ready.
Ingress has not yet been reconciled.
Waiting for load balancer to be ready.
Run 'ibmcloud ce application get -n myapp' to check the application status.
OK