End To End Test
Introduction
So far, you have deployed your application and CICD pipelines; additionally you have created webhooks and they are, apparently, working properly but we will never know for sure unless we make a change in the code and see if it all works as expected and we see that change being promoted through our environments. It’s about time for an end to end test!
The next diagram summarizes the end to end test you are going to run. As you can see, you will make a change to the code of the Kitchensink Application (kitchensink) which, via a webhook, will trigger the CI pipeline and hence the promotion of code.
These are the high level sequence of events (only relevant steps are mentioned, more details later on):
-
Change the code and push those changes to the repository of code (kitchensink in this case).
-
The Push Event is sent by the webhook to the kitchensink CI Pipeline Event Listener which in its turn triggers the pipeline by creating a PipelineRun object.
-
The
buildstep builds the image for kitchensink and pushes it to the registry, the hash of the new image is used to update the kustomization.yaml file in the dev overlay, in a short-lived feature-branch in the configuration repository (kitchensink-conf) -
A Pull Request is created for merging the
feature branchwith themain branchin thepr-createstep. -
The PR has to be confirmed so that changes are effectively merged into the main branch (this is a manual step)
-
Once the PR is confirmed, the merge is effective and a Pull Request Event is sent by the corresponding webhook to the kitchensink CD Pipeline Event Listener which in its turn triggers the pipeline by creating another PipelineRun object. At this point the hash of the new image has replaced the previous one.
-
The CD pipeline fetches configuration not code and in parallel triggers the sync of kitchensink-kustomized-helm-app-dev which means the new hash of the image is replaced in the Deployment object and hence a rolling update is triggered. Once the app is in sync a new PR is created to promote the code to the next environment.
Steps 6 and 7 are repeated for each environment until the code has been promoted to all of them.
Ok, done with the introduction, let’s get down to work!
Ⓐ Current Status
Before kicking off the demo let’s check the current status of Kitchensink. In order to do it, please open the next to link in both tabs so that you can watch the status of our app all the way through out the demo.
Use this link to watch the status of Kitchensink in dev.
https://kitchensink-helm-kustomize-dev-%USERNAME%.apps.%BASE_SUBDOMAIN%/index.jsfAnd this link to watch the status of Kitchensink in test.
https://kitchensink-helm-kustomize-test-%USERNAME%.apps.%BASE_SUBDOMAIN%/index.jsfⒷ Change the code
You’re going to make the same change you did in while testing hot reloading in chapter Redeploying a JBOSS EAP application. This time though you will make the change in the repository of code itself.
Copy the next URL and paste it in a new tab.
https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink/_edit/main/src/main/webapp/index.xhtml#L27Around line 27 make the next change:
<p>You have successfully deployed the JBoss Application in OpenShift</p>With:
<p>You have successfully deployed the Kitchensink in OpenShift !!!</p>Commit changes, scroll down, add a commit message and click on the Commit changes button.
Ⓒ Run the CI pipeline
The Push Event generated by the webhook defined in kitchensink repo triggers the pipeline named kitchensink-ci-pl. Let’s check that out.
Copy the next url to the OpenShift console that should take you to the Pipelines area and open it in a new tab. Then have a look to the kitchensink-ci-pl pipeline which should have been triggered and hence running.
https://console-openshift-console.apps.%BASE_SUBDOMAIN%/dev-pipelines/ns/cicd-tekton-%USERNAME%|
Click on the PLR link to see the diagram of the on-going or finished pipeline run; or in the Task Status Progress Bar to see the logs of tasks and steps. |
Click on the PLR link (red rectangle on the left), eventually you’ll see something like this. As you can see this is the representation of the pipeline including the status (in this case all green) of the tasks and also if any of them were skipped (grayed out).
Pay attention to the last task. As you can see it is actually two tasks in parallel but only one (gitea-pr-create) has been run, the other one (github-pr-create) has been skipped because in this case the git provider is Gitea.
This is so because there is a when expression in both tasks checking the GIT_PROVIDER parameter against github and gitea have a look to both tasks below.
- name: github-pr-create
...
runAfter:
- update-image
taskRef:
kind: ClusterTask
name: github-pr-create
when: (1)
- input: $(params.GIT_PROVIDER)
operator: in
values:
- github| 1 | This task is run if GIT_PROVIDER is github[1] |
- name: gitea-pr-create
...
runAfter:
- update-image
taskRef:
kind: ClusterTask
name: gitea-pr-create
when: (1)
- input: $(params.GIT_PROVIDER)
operator: in
values:
- gitea| 1 | This task is run if GIT_PROVIDER is gitea[2] |
So if the pipeline has finished well, the new image should have been pushed to the internal registry. Additionally the kustomization.yaml file of the dev overlay has been updated with the hash of the new image in a short-lived feature branch and finally a PR should have been created.
Let’s check all that out, let’s start with the image. Copy the following link and open it in a browser.
https://console-openshift-console.apps.%BASE_SUBDOMAIN%/k8s/ns/cicd-tekton-%USERNAME%/imagestreamtags/kitchensink:latest/historyYou should see an image recently pushed as in the next picture.
If you click on the download icon and then choose Docker Pull (by digest) you can find the SHA256 has at the end of the command.
|
Now it’s time to check it the PR has been created and includes the change of kustomization.yaml as expected.
Please copy this link and open it.
https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink-conf/pullsYou should see something like this, please click on the open PR.
In the body of the PR there’s information that helps the person who is to approve the PR that also will be used by the CD pipeline which should be triggered once the PR has been merged.
Please go ahead and have a look to the ±Files changed area. Once you’re done click on the Conversation link.
You should see changes made to file ./events-deployment/overlays/dev/kustomization.yml.
|
Ok, both the image and the PR are where they’re supposed to be, let’s move on!
Ⓓ Run the CD pipeline (dev)
So the CI pipeline has prepared everything to start with the actual deployment of a new version of the Kitchensink service. If you weren’t using GitOps the CD pipeline would (probably after an Approval Task) start by updating the image in the Deployment object using the Kubernetes API, but that’s not the case here. The Approval Task you would use in a Jenkins pipeline has been replaced by a PR and changes to the Deployment object in the OpenShift cluster have been replaced by ArgoCD reconciling changes from the source of truth (git repository) to the OpenShift cluster.
Approve PR
Well, it’s time to continue where we left it, so go back to the PR and click on the Create Merge Commit then tick the Delete Branch check-box (we wont need that branch anymore) and click again on Create Merge Commit.
CD Pipeline Triggered
The Pull Request event is sent out by the webhook to the Kitchensink CD Pipeline EventListener where some mapping and filtering will trigger the pipeline with a PipelineRun object populated with the necessary information.
Please, open the next link or navigate to Pipelines in project tekton-cicd-%USERNAME% you will see the pipeline progressing.
https://console-openshift-console.apps.%BASE_SUBDOMAIN%/dev-pipelines/ns/cicd-tekton-%USERNAME%| As you have done previously you can click on the PLR object to drill down and have a look to the logs. |
Have a look at the pipeline details. As you can see there are several tasks, namely:
-
argocd-synctriggers the refresh and sync of descriptors coming from the corresponding overlay[3],devin this case -
fetch-config-repositoryclones thekitchensink-confconfiguration repository -
update-imagecreates a short-lived branch and updates the image hash in thekustomization.yamlfile for the corresponding overlay -
github-pr-createcreates a PR for Github (not run) -
gitea-pr-createcreates a PR for Gitea
ArgoCD App Synced
Open the following link to see the new Application objects you just created through the ApplicationSet in ArgoCD UI.
https://openshift-gitops-server-openshift-gitops.apps.%BASE_SUBDOMAIN%/applications?labels=username%253D%USERNAME%%2Ckustomized-helm%253DtrueⒺ Run the CD pipeline (test)
This time we’re going to do this a bit faster and with less talking. This chapter is essentially the same as the previous one, but if you have access to an additional cluster and you have run section Register Additional Clusters, then you will see how Kitchensink is also updated in the additional cluster.
Approve PR
Open the Pull Requests area in the kitchensink-conf as you did before, have a look to the modified files and then approve it:
https://repository-gitea-system.apps.%BASE_SUBDOMAIN%/%USERNAME%/kitchensink-conf/pullsCD Pipeline Triggered
Use the the next link or navigate to Pipelines in project tekton-cicd-%USERNAME% you will see the pipeline progressing.
https://console-openshift-console.apps.%BASE_SUBDOMAIN%/dev-pipelines/ns/cicd-tekton-%USERNAME%ArgoCD App Synced
Open the following link to see how this time the test variant is the one being synced.
https://openshift-gitops-server-openshift-gitops.apps.%BASE_SUBDOMAIN%/applications?labels=username%253D%USERNAME%%2Ckustomized-helm%253Dtrue