Skip to main content

CI/CD Integration

Null Autos is built to be driven from pipelines. This guide shows how to use the platform in GitLab CI/CD: authenticating without managing secrets, launching emulators for tests, and benefiting from warm, snapshot-backed builds.

Authentication in pipelines​

The cleanest part: you do not manage credentials. Inside a GitLab pipeline, nullctl and the API automatically accept the GitLab CI job token (CI_JOB_TOKEN) that GitLab injects into every job. No service account keys, and no stored secrets.

note

The identity must be known to the platform. If a job-token call is rejected, make sure the acting user or group has been linked and granted access in your tenant. See Identity & Access.

Running tests against an emulator​

A test job typically launches an emulator from a snapshot, exercises it, and tears it down:

test-on-emulator:
  script:
    # nullctl picks up CI_JOB_TOKEN automatically
    - nullctl create emulator --snapshot "$SNAPSHOT" --name "$CI_JOB_ID"
    - EMULATOR_ID="$CI_JOB_ID"
    - nullctl adb connect "$EMULATOR_ID" &
    - adb wait-for-device
    - adb install build/app.apk
    - ./run-tests.sh
  after_script:
    - nullctl delete emulator "$EMULATOR_ID"

The same flow works over the REST API if you prefer calling it directly:

  • POST /api/v1/emulators to create,
  • the ADB proxy or VHAL gRPC to interact, and
  • DELETE /api/v1/emulators/{id} to clean up.

Warm, snapshot-backed builds​

For build jobs, the platform restores and captures snapshots automatically. A job opts in by declaring a few environment variables that tell the platform:

  • where to mount the managed volume,
  • which snapshots to restore from, and
  • when to capture a new snapshot (on success, on failure, or always).

The result: jobs start with prior build state already present and save their result for the next run, with no manual volume lifecycle and automatic retention so storage stays healthy. See Snapshots and Android Builds.

Coordinating multi-repository changes​

Large automotive projects span many Git repositories. Null Autos provides atomic cross-repository changesets so a single logical change can land across several repos together, with a merge that rolls back if any repo fails. This is driven by the nullctl multirepo tool and integrates with GitLab merge requests. See Multi-repo changesets.

Best practices​

  • Always clean up emulators in after_script so a failed job does not leak capacity.
  • Pin snapshots for reproducible test runs.
  • Parallelize with multiple emulators to shard large suites, keeping your tenant's per-user limits in mind.
  • Drive vehicle state with VHAL to cover automotive scenarios.

Next steps​