Testcontainer timeout with CPT

Hi @hakanostrom!

You’re absolutely right about your theory - this is a known issue with the Camunda Process Test (CPT) library when using Testcontainers in CI/CD environments like GitLab. Several users have reported similar timeout and performance issues, particularly in pipeline environments.

Root Cause

CPT uses Testcontainers by default, which spins up the full Camunda Docker image for each test run. In CI environments, this can be problematic due to:

  • Container startup/pull being slow (network, Docker-in-Docker overhead)
  • Resource contention even with generous memory allocation
  • Testcontainer startup timeouts in constrained CI environments

Recommended Solution: Switch to Remote Runtime

The most effective solution is to configure CPT to use remote runtime instead of Testcontainers. This way, you start Camunda as a separate service in your pipeline and CPT just connects to it.

Step 1: Configure your GitLab CI pipeline

Add a Camunda service to your .gitlab-ci.yml:

test:
  services:
    - name: camunda/camunda:8.8.0
      alias: camunda
  variables:
    CAMUNDA_ZEEBE_GATEWAY_NETWORK_HOST: "0.0.0.0"
  script:
    - mvn test

Step 2: Configure CPT for remote runtime

In your application-test.yml (or test properties):

camunda:
  process-test:
    runtime-mode: remote
    zeebe:
      gateway-address: camunda:26500
    # Add other connection details as needed

Your test class stays the same:

@SpringBootTest
@CamundaSpringProcessTest
public class MyProcessTest {
    // Your existing test code
}

Alternative: Optimize Testcontainers (if you must keep it)

If switching to remote runtime isn’t feasible, you can optimize the Testcontainers setup:

camunda:
  process-test:
    camunda-docker-image-name: camunda/camunda
    camunda-docker-image-version: 8.8.0
    connectors-enabled: false  # Reduces startup time

You can also adjust assertion timeouts for slower CI environments:

CamundaAssert.setAssertionTimeout(Duration.ofMinutes(1));

Why This Happens

The CPT with Testcontainers is significantly slower than the old Zeebe Process Test library, and many users have reported longer pipeline times after migration. The remote runtime approach eliminates the container startup overhead entirely.

References:

Let me know if you need help with the specific GitLab CI configuration or if you run into any issues with the remote runtime setup!