Skip to content

Integrating with CI/CD

Check out our latest blog post to follow tutorial steps for our GitOps-friendly Cloud-native test orchestration/execution framework.

In order to automate Testkube runs, access to a K8S cluster is needed, for example, a configured environment with the set up context and kubeconfig for communication with the K8S cluster.
Testkube uses your K8S context and access settings in order to interact with the cluster and tests resources, etc.

In the next few sections, we will go through the process of Testkube and Helm (for Testkube's release deploy/upgrade) automations with the usage of GitHUb Actions and GKE K8S.

Configuring your GH Actions for the Access to GKE

To obtain set up access to a GKE (Google Kubernetes Engine) from GH (GitHub) actions, please visit the official documentation from GH:

  1. Create a Service Account (SA).
  2. Save it into GH's Secrets of the repository.
  3. Run either Helm or Kubectl kubtest commands against the set up GKE cluster.

Main GH Action Section Configuration

To install on Linux or MacOS, run:

      # Deploy into configured GKE cluster:
      - name: Deploy
        run: |-
          helm upgrade --install --atomic --timeout 180s testkube helm-charts/testkube --namespace testkube --create-namespace

In addition to Helm, you can run any other K8s-native command. In our case: kubectl kubtest...

Complete Example of Working GH Actions Workflow and Testkube Tests Usage

Testkube tests can be easily re-used with minimal modifications according to your needs.

To run tests on Linux or MacOS:

name: Running Testkube Tests.

      - 'charts/**'
      - main

  PROJECT_ID: ${{ secrets.GKE_PROJECT }}
  GKE_CLUSTER_NAME_DEV: ${{ secrets.GKE_CLUSTER_NAME_DEV }}    # Add your cluster name here.
  GKE_ZONE_DEV: ${{ secrets.GKE_ZONE_DEV }}   # Add your cluster zone here.
  DEPLOYMENT_NAME: testkube # Add your deployment name here.

    name: Deploy
    runs-on: ubuntu-latest
    needs: notify_slack_if_release_succeeds
      - name: Checkout
        uses: actions/checkout@v2
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config "$GITHUB_ACTOR"
          git config "$"

      # Setup gcloud CLI 
      - uses: google-github-actions/setup-gcloud@94337306dda8180d967a56932ceb4ddcf01edae7
          service_account_key: ${{ secrets.GKE_SA_KEY }}
          project_id: ${{ secrets.GKE_PROJECT }}

      # Configure Docker to use the gcloud command-line tool as a credential
      # helper for authentication
      - run: |-
          gcloud --quiet auth configure-docker

      # Get the GKE credentials so we can deploy to the cluster
      - uses: google-github-actions/get-gke-credentials@fb08709ba27618c31c09e014e1d8364b02e5042e
          cluster_name: ${{ env.GKE_CLUSTER_NAME_DEV }}
          location: ${{ env.GKE_ZONE_DEV }}
          credentials: ${{ secrets.GKE_SA_KEY }}

      # Installing Testkube CLI:
      - name: Install Testkube CLI
        run: |-
          bash < <(curl -sSLf )

      # Run Testkube test on a GKE cluster
      - name: Run Tests
        run: |-
          kubectl testkube run test TEST_NAME

Along with the kubectl command, you can pass all the standard K8s parameters such as --namespace, etc.

If you wish to automate the CI/CD part of Testkube's Helm release, use Helm blocks as follow:

      - name: Install Helm
        uses: azure/setup-helm@v1
          version: v3.4.0

      - name: Installing repositories
        run: |
          helm repo add helm-charts
          helm repo add bitnami

      # Run Helm delpoy/upgrade of the Testkube release on a GKE cluster
      - name: Deploy
        run: |-
          helm upgrade --install --atomic --timeout 180s testkube helm-charts/testkube --namespace testkube --create-namespace