Container testing and validation in CloudBees workflows

Learn how to apply container scanning, testing, and compliance checks in CloudBees workflows to validate your containerized applications before deployment.

You can integrate container vulnerability scanning, unit and integration tests, and compliance gates directly into your CI/CD pipelines using CloudBees workflows. This content explains how to structure testing steps, pass artifacts between jobs, and use best practices to ensure your containerized applications are ready for release.

Use cases

Use container testing in CloudBees workflows to:

Scan container images for vulnerabilities before deployment.
Run unit and functional tests in containerized environments.
Validate service-to-service integration during builds.
Enforce compliance gates using native policy actions.

Vulnerability scanning with Trivy

Scan a container image for vulnerabilities using the CloudBees-supported Trivy action.

- name: Scan container image
  uses: https://github.com/cloudbees-io/trivy-scan-container
  with:
    image-location: "example.com/local/alpine"
    image-tag: "latest"
    server-url: "${{ vars.TRIVY_SERVER_URL }}"▼

This step runs a vulnerability scan using the Trivy scanner. You can view scan results in the platform UI or use them to block promotion.

This example uses Trivy, a commonly adopted open-source tool. You may update this with alternative tools such as Snyk.

Functional and unit testing in a container

You can run test commands in container-based steps.

- name: Run application tests
  uses: docker://node:16
  run: |
    npm install
    npm test▼

This example installs dependencies and runs tests in a Node.js 16 container.

Each workflow step runs in an isolated container. To make files or dependencies available across steps, install them into a shared location such as /cloudbees/workspace.

You can access this directory using:

The ${{ cloudbees.workspace }} context variable
The CLOUDBEES_WORKSPACE environment variable

The home directory ($HOME) is also shared across steps within a job.

Integration testing using services and jobs

To validate service-to-service interactions, use separate jobs: one to build your container image and another to test it with a companion container. Each job in a CloudBees workflow runs in its own Kubernetes pod, where all containers must be provisioned before the pod starts. Because of this behavior, images built during a job aren’t immediately available to steps within that same job. Using separate jobs ensures the image is fully built and available for testing in a subsequent job.

The following example shows two jobs:

build-image: Builds the container image.
run-tests: Runs integration tests using the built image by launching it alongside the test container in the same job.

jobs:
  build-image:
    steps:
      - name: Build container image
        uses: https://github.com/cloudbees-io/kaniko@v1
        with:
          destination: myregistry/my-backend-service:${{ cloudbees.scm.sha }}

  run-tests:
    needs: [build-image]
    services:
      backend:
        image: myregistry/my-backend-service:${{ file.scm.sha }}
        ports:
          - 8080
    steps:
      - name: Run integration tests
        uses: docker://node:16
        run: |
          npm install
          npm run integration-tests▼

Each job in a workflow runs in isolation. Background processes or services started during one step or job are not shared with others. For integration testing, run dependent services alongside your test container using additional container definitions. Avoid bundling multiple services into a single container, as it can complicate reuse and conflict with best practices for maintainability and image size.

CloudBees workflows do not support Docker Compose YAML files. Use additional containers defined in the job configuration or run multiple services in the same container when needed.

Compliance and policy enforcement

You can enforce compliance gates and policy logic to ensure containers meet your organization’s requirements.

Require approval for deployments of images with known vulnerabilities.
Enforce naming conventions or tag requirements.
Use policies to fail builds that violate compliance standards.

Here is an example of adding a compliance check as a workflow step:

- name: Enforce image policy
  uses: cloudbees-io/policy-eval@v1
  with:
    input-file: scan-results.json
    policy-id: container-security-policy▼

This step runs a policy evaluation against the container scan results. The workflow will fail if the image violates the specified policy, preventing non-compliant images from progressing to deployment.

Refer to Network security policy settings for more general information.
Refer to Create a ServiceNow change request for another usage example.

The exact usage and available policy integrations may vary based on your organization’s policy engine or configuration.

Best practices

Keep test containers lightweight and use well-maintained base images.
Separate functional, integration, and security tests for easier debugging.
Use meaningful names for each step to improve traceability.
Run dependent services and test logic within the same job using additional containers defined alongside your primary test container.

Container testing and validation in CloudBees workflows

Use cases

Vulnerability scanning with Trivy

Functional and unit testing in a container

Integration testing using services and jobs

Compliance and policy enforcement

Best practices

Next steps