Skip to content
RecipesDoc

GitLab CI Calls Certyn After Deploy and Gates on the Result

Your GitLab pipeline starts a Certyn suite after each deploy, waits for it, and fails the job when tests fail.

For teams on GitLab who want a deploy to stop when Certyn's smoke tests fail.

Your setup

  • GitLab CI (gitlab.com or self-managed) with a deploy job, for example to staging.
  • Certyn test cases for your critical paths.
  • You want the pipeline to fail when they fail.

Say this to Certyn

After our GitLab pipeline deploys to staging, run the smoke tests and fail the pipeline if they fail.

What Certyn does

  1. Makes sure there is a suite to run: a Certyn suite process for your smoke test cases (app.process.create, type certyn), for example smoke-suite.
  2. Opens the ci_setup form. Pick GitLab CI/CD. It creates an API key and shows it once.
  3. You save the key as a protected, masked CI/CD variable CERTYN_API_KEY.
  4. Certyn gives you a certyn-smoke job for .gitlab-ci.yml. Put it in a stage after your deploy job. The job uses curl and jq to:
    • start the suite: POST /api/ci/runs with projectSlug, environmentKey, processSlug (smoke-suite) and commitSha, with the X-API-Key and Idempotency-Key headers;
    • poll GET /api/ci/runs/{runId} until state is completed or cancelled;
    • exit with an error when failed > 0 or blocked > 0.

The full job is in GitLab and Other CI.

What you get

  • A red pipeline when a smoke test fails or is blocked, with a link (appUrl) to the Certyn run.
  • A run report, and a Certyn issue with evidence for each real product bug.
  • CI retries with the same Idempotency-Key do not start a second run.

Limits

  • The CI Runs API runs Certyn suites (by processSlug or tags). It cannot start an agent process, such as your own repo's tests. To get those into Certyn, push their results.
  • Certyn does not set GitLab CI/CD variables or change your pipeline here. You add the key and the job.
  • If staging is on a private network, Certyn's runs need a self-hosted runner.