Skip to content

Contribution testing workflow

The Contribution testing workflow is a quality assurance process designed to validate code changes in a containerized environment before integration into the main codebase^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. This workflow places the responsibility of testing and building on the contributor, ensuring that changes are verified using the contributor's own resources before requesting official repository updates^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

Prerequisites

The core requirement for this workflow is that the PR owner must perform appropriate testing using images built and pushed to their own Docker repository^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. This prevents unstable or untested code from affecting the official infrastructure^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

Workflow Steps

The process consists of three main phases: building Docker images, pushing them to a registry, and deploying for verification^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

1. Build Docker Images

The first step involves building the service images locally^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. This is typically done via a script that accepts a version tag and a registry prefix^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

src/build-services.sh <version> <prefix>

For example: 

src/build-services.sh 1.16.3 docker.io/username

2. Push Images and Update Manifests

Once the local build is successful, the images must be pushed to a container registry^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. Simultaneously, the YAML deployment manifests must be updated to reference the new tag^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. A unified script is often provided to handle building, pushing, and updating YAML files in a single step^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

./build_push_update_images.sh <version> --prefix=<prefix>

3. Deployment and Verification

After pushing the images, the application is deployed to a cluster to verify functionality^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

  • Deploy: Apply the updated YAML manifests to the cluster^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].
  • Verify Pod Status: Ensure all pods reach the Running state^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].
  • Functional Testing: Verify the application works as expected. This can be done by executing a command inside a running Pod (e.g., using curl to check a specific endpoint) or by accessing the application URL via a browser^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

Example verification command: 

[kubectl](<./kubectl.md>) exec -it "$([kubectl](<./kubectl.md>) get [Pod](<./pod.md>) -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"

Post-Test Procedures

If the testing phase completes successfully and the application functions as intended, the contributor should request that the reviewer build and push a new official set of images^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]. Additionally, the contributor should add another commit to the original Pull Request containing the necessary version changes^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md].

Sources

^[400-devops__07-Monitoring-and-Observability__k8s-istio__samples__bookinfo__README.md]