Atrahasis in CI/CD
Getting Atrahasis into a pipeline takes one line. No agent to install, no plugin to get approved, no account, no licence check and no CI-specific build. One command fetches a single binary on the runner and runs your tests, on any platform that can run a shell command.
Three things run there. A request with assertions, to prove a deploy answered. A flow, to prove a feature still works end to end. A load test, to prove it holds up under traffic. Flows and load tests are the ones you designed in Atrahasis and committed to git, so your pipeline runs exactly what you ran in the app.
In the app
- Flow
- logout
- Environment
- dev
You design the flow, pick an environment, and watch it pass.
In your pipeline
The same two choices, named on the command line.
That is the entire translation. The flow and the environment you picked in the app become the two flags the pipeline passes, and everything behind them, the requests, the assertions, the variables, comes from the folder you committed. Nothing is exported, converted or rewritten for CI.
Nothing to install
No agent, no plugin, no account and no licence check. One command fetches a single binary on the runner and runs it.
Three tools, one binary
API client, flow runner and load tester. The jobs teams usually spread across three tools, at one version, from one command.
A failed check fails the build
Any failed assertion or breached threshold exits non-zero. No wrapper script and no parsing of the log.
Three jobs in a pipeline
These are the three things atra is asked to do in CI. Most projects end up using all three: a request to prove the deploy answered, a flow to prove the feature still works end to end, and a load test to prove it holds up.
Send a request and check the answer
A smoke test after a deploy, with no file to author and nothing to check into the repository. Everything lives in the one command: the method, the URL, and the assertions that decide whether the step passes.
atra GET https://api.example.com/health \ -a "status eq 200" \ -a "$.status eq UP" \ -a "response_time lt 2000"
Run a flow built in the app
A flow is a sequence of requests that passes values between steps: log in, take the token, create an order, read it back. You draw it in Atrahasis, commit the folder, and the pipeline checks it out and runs it.
atra run -f logout -e dev
Run a load test built in the app
The same idea for load. Pick the spec and the profile, and atra runs it headless with the thresholds you set in the app deciding pass or fail.
atra run -s logout -t load -e dev
Where flows and load tests come from
You do not write flows or load specs by hand for CI. You build them in Atrahasis, where you can run them, watch the responses and fix them interactively. The app writes plain files to a folder, that folder goes into git, and the pipeline checks it out.
1. Build it in the app
Design the flow or the load spec in Atrahasis and get it passing there first. A pipeline is a poor place to debug one.
2. Commit the folder
The group folder holds the flows or specs and an environments.json. Push it to a repository.
3. Check it out in CI
The pipeline clones that repository and runs atra inside the folder. No export step, no second format.
Keep them in their own repository: tests usually outlive and outgrow a single service, and several pipelines often want the same flow. A separate repository lets each pipeline check out only what it runs, and lets you version the tests without touching application code. The platform pages show the checkout step for exactly this reason.
Why the build actually turns red
Every CI platform decides pass or fail the same way: it looks at the exit code of the command. atra exits 0 when every assertion passed and non-zero when any of them did not. That covers a failed assertion in a single request, a failed step in a flow, and a threshold or assertion breach in a load test.
This matters more than it sounds. A test runner that prints a failure but still exits 0 gives you a green pipeline over a broken API, and nobody reads the log of a green build. No wrapper script, no output parsing and no grep over stdout is needed to make this work.
Where to go next
Each platform page in the sidebar is complete on its own and covers all three jobs, so you only need to read the one you use. Start with Environments if your tests need a base URL or a credential, which is nearly always.
Not seeing your platform? A platform gets its own page here once atra has actually been run on it, rather than because the YAML looked plausible. Until then the Any CI system page gives you the same four decisions in a form you can apply anywhere.