Log inStart free

Use cases

Test data for CI/CD pipelines

How a build pipeline gets its own copy of a policy-certified dataset for each run, cleans it up afterwards and keeps value-free evidence - without the pipeline touching production.

Use case

Continuous integration promises that every change is tested the same way, automatically. Test data usually breaks that promise. Pipelines share one long-lived database that someone refreshes by hand, tests pass or fail depending on which branch ran last, and the fastest fix anyone can think of is to hand the pipeline a copy of production. This page describes what DataNivra provides for pipelines today, what the pipeline does at each step, and the limits you should plan around.

What a pipeline needs from test data

A pipeline needs data that is realistic enough to exercise real code paths, isolated so one run cannot disturb another, repeatable so a failure can be investigated against exactly the same rows, and safe so that automation never widens who can see personal or financial values. It also needs the data quickly: a test stage that waits hours for a manual refresh is not continuous anything.

Most teams can meet two or three of these at once. The usual trade-off is speed against safety: a nightly clone of production is fast to use and realistic, but it copies sensitive values into an environment with weaker controls and many more readers.

What DataNivra provides today

  • Environment leases. A pipeline asks for one certified dataset version in one ephemeral target environment for a bounded time. The control plane checks that the version is still provisionable (certified, unexpired, not revoked, evidence complete, signed certificate valid) before anything is written, and refuses otherwise.
  • CI-aware requests. The datanivra env-leases commands read only identifiers from the job environment of GitHub Actions or GitLab CI: repository, pull request or merge request number, run id and commit. A retried step replays the same lease instead of creating a second one, and a re-run of the same commit gets the still-live lease back.
  • Clean-up you can rely on. Releasing a lease is idempotent and safe to call from an "always run" step. A lease that nobody releases lapses at its time-to-live, and the example workflow's clean-up job (datanivra env-leases release-ci) releases every live lease of a pull request when it closes. A lease counts as released only after your agent confirms the copy is gone.
  • Value-free evidence. The evidence of a lease lists state changes, the certificate id and digest, hydrate and teardown receipts, timings and the CI reference, protected by a SHA-256 digest that the CLI re-verifies. It contains no test-data values, so it can be attached to a test report.

The pattern is exercised end to end against a real control plane and agent in DataNivra's own test suite, including the teardown check in the target and the evidence digest.

How a run uses it

  1. The job creates a lease for a certified dataset version and an ephemeral environment your administrator registered, and waits until it is ready.
  2. Your agent, inside your network, writes the copy into the target. Rows never pass through the pipeline or through DataNivra Cloud.
  3. The tests run against the target.
  4. An "always run" step releases the lease and saves the evidence file next to the test results.

The example GitHub Actions workflow in the repository follows exactly these steps, and the TDM in CI/CD tutorial explains the reasoning behind each of them.

Limits to plan around

  • DataNivra does not create databases, containers or namespaces. The target is whatever your agent reaches through the environment's secret reference; the ephemeral environments use case describes the target options.
  • The datanivra CLI is not on PyPI yet; install it from a verified client-package release (see the CLI documentation). The REST API and SDKs offer the same operations.
  • Plan limits apply to live leases per tenant and per user and to lease hours per month. Time-to-live is between five minutes and seven days per request, with an absolute end of at most thirty days.
  • Certification here means DataNivra-certified against configured policy gates. It is not a regulatory or third-party certification, and it does not make a pipeline compliant with any regulation.

Next steps

Score your current pipeline with the CI/CD test-data checklist, read the API overview for idempotency keys and error codes, and start free to try the request flow against the synthetic sandbox.