Continuous Integration and Continuous Delivery (CI/CD) are a transformative methodology that has redefined how software is developed and delivered. These are the game-changing processes that automate code integration, testing, and deployment, streamlining workflows, enhancing software development lifecycles, and maintaining their quality.

Testing is a critical part of any CI/CD pipeline as it ensures software quality. Most modern CI/CD tools allow you to configure testing tools within your pipeline. Jenkins is one of the most popular open-source CI/CD tools as it plays a vital role in orchestrating your entire pipeline. From code integration and testing, to deployment and monitoring.

In this blog post, we delve into CI/CD and testing. We’ll explore how Jenkins, coupled with Testkube, can simplify and enhance the testing process within the CI/CD pipeline - so you can get set, build, test, and deploy!

What is Testkube?

Testkube is a Kubernetes-native testing framework designed to execute and orchestrate your testing workflows inside your Kubernetes clusters. It allows you to bring your chosen testing tool to run all types of tests, integrate them out of the box, and schedule them from within your cluster, while providing all the visibility into your tests and flexibility when building and executing these tests from your CI/CD processes.

Kubernetes Automation Testing with Jenkins

Jenkins facilitates the creation of a well-defined CI/CD pipeline, ensuring order and efficiency throughout the software development process. With Jenkins, you can seamlessly integrate version control tools like GitHub, GitLab, etc, making your codebase organized and accessible. 

Setting up CI/CD pipelines with Jenkins or any other tool is critical in modern software development, but integrating testing tools within these pipelines presents several complexities. The challenge arises from diverse testing requirements, the need for careful tool selection, managing versions and environments, orchestrating parallel test execution, and efficient test data management.

Despite these complexities, integrating testing tools is essential. An effective CI/CD pipeline with integrated testing tools streamlines software development, enhancing both quality and speed.

Testkube and CI/CD Pipelines

Creating testing workflows within CI/CD pipelines can be a daunting task, given the number of steps and configurations involved. With numerous components and dependencies, these pipelines often grow complex, making it difficult to visualize and manage the entire process effectively. However, the transition becomes remarkably straightforward with Testkube.

Testkube offers seamless integration with a variety of testing tools, streamlining the entire process and making it effortlessly efficient. This also provides better separation between CI/CD and the testing process.

This means that, as a user, the experience of setting up Postman in a CI/CD pipeline using Testkube is the same as setting up K6 on Testkube, thus ensuring consistency in integration across all tools. 

Using Testkube in Jenkins

To understand how to use Testkube in Jenkins, let’s look at a simple use case where we will showcase the power of this integration. We’ll configure Jenkins to run Testkube tests when a new PR is opened in a particular repo. Internally it will create and execute a Testkube test and based on the results of the test, the result will be shared back into the PR to the developer. 

Let’s see how the integration of Testkube with Jenkins works.

Pre-requisites

• Kubernetes cluster with Testkube configured - we’re using an EKS cluster. Refer to Testkube installation docs to install Testkube.
• Jenkins

We are going to use a sample application to run our tests against this repo. 

For this implementation to work, you need to first configure Jenkins and GitHub before configuring Testkube.

Configuring GitHub

The first step here is to configure your GitHub repository to communicate with your Jenkins instance. This will enable GitHub to send events like the opening of a PR to Jenkins and allow Jenkins to return the test status to GitHub.

Start by creating a Personal Access Token (PAT) for your account. This will be used while configuring Jenkins.

The next step is to configure a webhook for your repository. This is required for GitHub to send events to your Jenkins instance. For instance, opening a PR is an event, so after creating a webhook, GitHub will be able to send PR open events to Jenkins.

To do that, navigate to your Project Settings and click WebHooks. Tap on New to create a new webhook. Enter your Jenkins URL under the Payload URL as shown below.

‍

‍

Make sure to also select the Pull Request event under the “Which events would you like to trigger this webhook?”

The next step is to configure the repo commit status so that it disables the merge option until the CI pipeline runs. Navigate to Repo -> Settings -> Branches -> Branch Protection Rule and enable Require status checks to pass before merging.

‍

Upon saving this, you have successfully configured your GitHub repository to communicate with your Jenkins instance. Let’s now shift our focus to configuring Jenkins.

Configuring Jenkins

Login to your Jenkins account and create a new Pipeline. You can create a pipeline using the CLI or through the UI. We have created it through the UI.

Pre-requisites

You must have your Personal Access Token (PAT)  ready that you created in your GitHub account.

Provide a name for your pipeline and move to the Plugins page to install the following plugins that are required for the Jenkins and Github integration to work:

• GitHub Pull Request Builder
• Docker
• Git
• Pipeline

‍

Note: Some of these can be enabled by default. But you should ensure these are installed and enabled.

The next step is to configure the GitHub pull request builder.

Go to Manage Jenkins -> Configure System and enter values in the GitHub pull request builder. Enter your PAT in credentials and test that Jenkins is able to communicate with GitHub via API using the test credentials option.

‍

‍

If the connection is successful, the next step is to configure Jenkins to trigger this pipeline using the events from your GitHub repository. 

Create a new pipeline in Jenkins and provide a name.

‍

Enter your repo URL in the GitHub project.

‍

Navigate to the Build trigger section of the GitHub pull request builder to configure the admin list which will be populated based on the PAT that you configured. Select the option to “Use GitHub hooks to automatically run the job after every pull request”. 

‍

Navigate to the advanced section and enable the following two options

• Close failed pull requests automatically.

• Build every pull request automatically without asking

In the pipeline option, select Pipeline Script and then enter the following Groovy script:

‍

```bash

def getCommitSha() {
  sh "git rev-parse HEAD > .git/current-commit"
  return readFile(".git/current-commit").trim()

}

‍

void setGithubBuildStatusConditional(String message, String state, String gitRepo, String conditional) {
  if ('false'.equalsIgnoreCase(conditional)) {

      // workaround https://issues.jenkins-ci.org/browse/JENKINS-38674
      commitSha = getCommitSha()
      step([
          $class: "GitHubCommitStatusSetter",
          reposSource: [$class: "ManuallyEnteredRepositorySource", url: gitRepo],
          commitShaSource: [$class: "ManuallyEnteredShaSource", sha: commitSha],
          contextSource: [$class: "ManuallyEnteredCommitContextSource", context: "ci/jenkins/build-status"],
          errorHandlers: [[$class: "ChangingBuildStatusErrorHandler", result: "UNSTABLE"]],

          statusResultSource: [ $class: "ConditionalStatusResultSource", results: [[$class: "AnyBuildResult", message: message, state: state]] ]
      ]);
  }
}

pipeline {
    agent any
‍
    stages {
        stage('Git Checkout') {
            steps {
                checkout changelog: true, poll: false, scm: [
                    $class: 'GitSCM',
                    branches: [[name: "test1"]],
                    doGenerateSubmoduleConfigurations: false,
                    extensions: [[$class: 'CloneOption', noTags: true, shallow: true, depth: 200]],
                    userRemoteConfigs: [[name: 'origin', url: "https://github.com/Dikshant1996/testkube-demo.git", credentialsId: "151b381c-f774-4e3b-9322-bbbe8b46f81c"]]
                ]
                // Status tracks commit message, so it has to be after the git checkout
                setGithubBuildStatusConditional("Build pending", "PENDING", "https://github.com/Dikshant1996/testkube-demo", "test1")
            }
        }
        stage('Create test') {
            steps {
                script {
                    // Run a script to create test
                    sh """
                    #!/bin/bash
                    docker run kubeshop/testkube-cli:latest create test --git-uri https://github.com/infracloudio/testkube-django-app.git \
                    --git-path myproject/examples/ \
                    --type ginkgo/test \
                    --name django-app-test \
                    --git-branch master --api-uri http://testkube-api-1691704505.ap-south-1.elb.amazonaws.com/results --client direct 

                    """
                }
            }
        }
        stage('Run test') {
            steps {
                script {
                    // Run a script to run test
                    sh """
                    #!/bin/bash
                    docker run kubeshop/testkube-cli:latest run test django-app-test --namespace testkube --api-uri http://testkube-api-1691704505.ap-south-1.elb.amazonaws.com/results --client direct --watch 

                    """
                }
            }
        }
    }
    

        post {
            
        success {
            setGithubBuildStatusConditional("Build success", "SUCCESS", "https://github.com/Dikshant1996/testkube-demo", "false")
        }
        failure {
            setGithubBuildStatusConditional("Build failed", "FAILED", "https://github.com/Dikshant1996/testkube-demo", "false")
        }
    }
}
```

‍

Make sure to change –api-uri with your domain in the create and run test section and repo URL. The above script basically instructs Jenkins job to create a Testkube test, execute it, and return the status of the test execution back to the pull request that triggered the pipeline.

Configuring Testkube

With this, we have successfully configured Jenkins with Testkube and the GitHub repository. Let’s see how this integration works. 

Raise a PR in the configured repository to see Testkube in action with Jenkins. 

‍

‍

As soon as the PR is raised, the Jenkins pipeline is triggered. This also initializes Testkube which in turn creates and runs the test on the target cluster.

Navigate to the target cluster and check if the tests are created or not. We see that the tests are created, executed, and failed as well. 

‍

‍

Once these tests are executed, you can view the results of these tests in your Jenkins pipeline as well.

We have configured Jenkins to execute the tests and share the result back to the respective pull request. If the test fails, GitHub will prevent the PR from being merged and will require an admin to approve and merge it. If the test is successful, the PR can be merged by the developer.

‍

In the above screenshot, you can see that the test has failed, the status will be updated in the pull request and it will not allow the developer to merge the pull request. You can configure branch protection rules in the respective repo to take appropriate actions based on your requirements.

However, when the test passes, the developer who raised the pull request will see the status in the PR and will have the option to merge the pull request. You can configure the next steps based on your requirements.

‍

‍

And that’s how you can integrate Testkube with Jenkins and run your tests as part of your CI/CD pipeline. You can configure the pipeline and Jenkins with further advanced configurations and utilize Testkube to suit your requirements.

Summary

In this blog post, we saw that the challenges in setting up complex testing workflows within CI/CD pipelines are time-consuming and complex. However, Testkube offers a refreshing perspective, where the integration of testing tools in a CI/CD pipeline becomes a seamless process. By providing standardized configurations and the flexibility to bring your preferred test tools into the fold, it simplifies the intricacies of the testing process

We also saw how Testkube can be integrated with the Jenkins pipeline that is triggered when a PR is opened, followed by the execution of a test and the results of which are shared back to the developer in the PR itself.

To experience the full potential of testing on Testkube, you can go ahead and give Testkube a try today.

Try out the various test types in Testkube and witness firsthand how Testkube simplifies and empowers your testing process with its Kubernetes-native capabilities. Join our Slack community for guidance and support.