LocalCloud GCP Integration Testing in CI
Get started
local.cloud — GCP Integration Testing in CI .md Open tab
Internal automation

Run LocalCloud in team CI

Run Google Cloud integration tests in CI against local endpoints. Keep the job isolated, pin the image, and validate against real Google Cloud separately. The Public Preview License permits ongoing internal CI for individuals and organizations, including for-profit companies.

Supported operations only

Select only operations supported by the current compatibility contract.

Wait for health

Do not run tests unless the health gate succeeds; retain logs when startup fails.

Test on your runner

Treat these as templates until exercised with a pinned image on the selected CI runner.

Technical examples for internal automation

Use these templates only within the governing Public Preview License. Exercise networking, health, image identity, and cleanup on the exact runner.

GitHub Actions
name: localcloud-integration-tests
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Start LocalCloud
        run: |
          # Public preview permits non-production internal organization and team CI.
          # Pin an image digest when the workflow must be repeatable.
          docker volume create localcloud-data

          docker run -d --name localcloud \
            -p 127.0.0.1:5380-5405:5380-5405 \
            -m 4g \
            -v localcloud-data:/var/lib/localcloud \
            agentcloud/localcloud:latest
          for i in $(seq 1 60); do curl -fsS http://localhost:5380/readiness && exit 0; sleep 2; done
          docker logs localcloud
          exit 1
      - name: Export emulator env and test
        run: |
          eval "$(curl -fsS 'http://localhost:5380/env?format=shell')"
          ./scripts/integration-test.sh

The GitHub Actions workflow guide covers the readiness gate and why the job needs no Google Cloud credentials.

GitLab CI
integration-tests:
  image: python:3.12
  services:
    - name: agentcloud/localcloud:latest
      alias: localcloud
  variables:
    BIGQUERY_EMULATOR_HOST: http://localcloud:5388
    PUBSUB_EMULATOR_HOST: localcloud:5383
  before_script:
    - pip install -r requirements.txt
    - |
      for i in $(seq 1 30); do
        if curl -fsS http://localcloud:5380/health; then exit 0; fi
        sleep 2
      done
      exit 1
  script:
    - pytest tests/integration/
Jenkins (Docker Pipeline)
pipeline {
  agent { docker { image 'python:3.12' } }
  stages {
    stage('Integration Tests') {
      steps {
        docker.image('agentcloud/localcloud:latest')
          .withRun('--memory 4g -p 5388:5388 -p 5383:5383') { c ->
            docker.image('appropriate/curl')
              .inside("--link ${c.id}:localcloud") {
                sh """
                  for i in $(seq 1 30); do
                    if curl -fsS http://localcloud:5380/health; then exit 0; fi
                    sleep 2
                  done
                  exit 1
                """
              }
            withEnv([
              'BIGQUERY_EMULATOR_HOST=http://localcloud:5388',
              'PUBSUB_EMULATOR_HOST=localcloud:5383'
            ]) {
              sh 'pytest tests/integration/'
            }
          }
      }
    }
  }
}

Write tests that exercise real SDK calls

Integration tests, including the ones a coding agent writes, are safer when they run against disposable localhost services first.

Test what can actually break

Use real SDK clients against LocalCloud for SDK routing, serialization, resource naming, query syntax, event flow, and setup and teardown. Keep pure unit tests for business logic, and don't mock service behavior.

Fail closed on routing mistakes

If emulator variables are missing or LocalCloud isn't ready, fail the job rather than fall back to production defaults. Print the active emulator endpoints before the tests run.

Run the suite locally first
set -euo pipefail
eval "$(localcloud env)"
export GOOGLE_CLOUD_PROJECT=local-gcp-project
./scripts/integration-test.sh

Let a coding agent prepare the first CI change

Keep the first change small and reviewable: start LocalCloud, wait for readiness, export the environment, and run the existing integration tests. Leave retries, deployment logic, and credential setup out of it.

Prompt
Read the LocalCloud Public Preview License and keep this workflow non-production. Prepare the smallest automation change that starts LocalCloud, waits for http://localhost:5380/readiness, exports emulator env vars, runs existing integration tests, and does not add real GCP secrets.

What local emulation can add

Local isolation

Exercise documented operations without routing the local test step to a real Google Cloud project.

Controlled state

Use one data volume, project, and fixture namespace per job. Create the minimum data each test needs or load seed fixtures, never depend on a previous run, and do not assume emulator concurrency or isolation matches Google Cloud.

Earlier feedback

Catch endpoint, request-shape, and fixture errors before the guarded real-Google-Cloud release step.

Credential boundary

The bounded local job should not need production GCP credentials. Stop if an SDK tries to reach Google Cloud; keep release credentials in a separate guarded job.

Frequently asked questions

Does LocalCloud support GitHub Actions, GitLab CI, and Jenkins?

Yes. This page has templates for all three. The Public Preview License permits non-production internal CI for individuals and organizations, including for-profit companies. Test runner networking and service-container behavior on your runner.

Will my tests behave differently in CI vs local development?

They can differ because of image identity, runner resources, networking, ports, concurrency, and retained state. Pin an image digest, isolate state, and validate production behavior separately.

Can I run parallel test suites against the same LocalCloud runtime?

Use one isolated data volume and project per job. Parallel clients can still contend for service state, resources, and ports; namespace fixtures and verify concurrency behavior rather than assuming isolation guarantees.

Review the license before automating LocalCloud

The Public Preview License permits organization and team CI for non-production development and testing. Keep LocalCloud isolated and validate production behavior separately.

Desktop view