Skip to main content
CI runs Gradle tasks of a git-linked project on every push and pull request, and reports the result back on the commit. It builds on the same Linux infrastructure as deployments, so there is nothing to set up besides turning it on.

​
Turn it on

CI is off by default. Open the project’s Settings tab and find CI, or use the CLI:
Changing the settings needs the Admin role. atoll ci enable keeps the tasks and branches you don’t pass; --all-branches goes back to every branch. The project must be linked to a repository first.

​
What runs

Every push to a matching branch, and every pull request that is opened, reopened or gets new commits, starts a run. A run downloads the commit, keeps the project’s root directory and runs ./gradlew <tasks> --continue there, so one failing task doesn’t hide the others. Runs are Linux only. A new push to a branch cancels that branch’s run if it is still queued or running, so only the newest commit is tested. Rerun a run to test the same commit again with the current settings and vars.

​
Pull requests from forks

Pull requests from forks run too, but never get secret env vars; plain ones are passed as usual.

​
Env vars

A run gets: The project’s deployment vars are not passed. Secret values are masked in the log.

​
Results

The project’s CI tab lists the runs with their status, branch, commit, message and duration. A run’s page shows its live log and the Gradle tasks that failed (from > Task :x FAILED lines). A run is QUEUED, RUNNING, PASSED, FAILED (a task failed), CANCELLED or ERROR (the platform couldn’t run it, not a test failure).
Run ids can be shortened to their first characters, as atoll ci ls shows them. Reading runs needs the Viewer role; rerunning and cancelling them needs Developer. Every run reports a commit status named atoll-ci/<project>: pending while it is queued or running, then success, failure (a task failed) or error (cancelled, or the platform couldn’t run it). To keep pull requests with failing tests from being merged, add atoll-ci/<project> as a required status check in the repository’s branch protection rules on GitHub. Runs and their logs are kept for 90 days.

​
Billing

CI time counts as build minutes, like deployment builds, and shows up as such on the org’s usage and invoices. An org that can’t deploy because its free allowance is used up or its spend limit is reached gets no new runs either: each push still shows up as an ERROR run with the reason, and the commit gets an error status.

​
Self-hosting

Runs use the builder image as Kubernetes Jobs with ATOLL_RUNTIME=kubernetes, and local Gradle otherwise. Commit statuses need the GitHub App’s Commit statuses permission, which git.md already asks for.