Other CI systems

A Testfile is a plain command: testfile start. Any CI system that can run a shell command can run your suite, and because the runner owns services, parallelism and matrices, the pipeline stays a single job instead of a translation of your test setup into that system’s YAML dialect.

Three systems get more than a template: the GitHub Action adds annotations, a job summary and artifact upload on top, the GitLab CI template is its include-able counterpart, and the Tekton Task runs the declared services as pods on the cluster the pipeline already runs on. For everything else, copy one of the templates in the repository’s ci/ folder:

The GitHub and GitLab ones are there for completeness — on GitHub the action is the better choice, since annotations, the job summary and per-test commit statuses are things a plain run: step cannot do, and on GitLab the include-able template adds filters, change-based selection, a doctor pre-flight and the labels that make a recorded run findable. Take a plain template when you would rather not depend on either.

There is also the opposite direction: testfile export generates a native pipeline — a GitHub workflow, a GitLab CI file, a Tekton Pipeline or a bash script — that runs the tests without the runner, translating sequences, parallelism, matrices and services into that system’s own constructs. Use it when a pipeline must not depend on the runner at all; the export page documents which features each target supports.

They all follow the same three steps:

npm ci --no-audit --no-fund
npx --yes @testfile.dev/runner start --reporter junit --output junit.xml
# then: publish junit.xml, archive .testfile/runs/

Two things are worth wiring up in every system:

• junit.xml feeds the system’s own test reporting.
• .testfile/runs/ is the recorded run — run.yaml, per-test logs, service logs, collected artifacts. Archiving it is what makes a CI run inspectable later, locally, in the same viewer as your own runs.

Bringing runs home

For GitLab, the viewer speaks the API directly:

export GITLAB_TOKEN=...                     # a token with read_api
testfile gitlab list group/project   # what is available
testfile gitlab sync group/project   # import the latest pipelines
testfile runs                        # they are part of the history now

--job <name> selects the job whose artifacts hold the run (default testfile), --latest <n> how many pipelines to consider, --ref <branch> narrows to one branch, and --host https://gitlab.example.com points at a self-hosted instance. On GitHub, the equivalent is testfile github sync.

For Jenkins, CircleCI, Buildkite — or any system whose artifacts you download by hand — import the downloaded archive:

testfile archive import testfile-runs.zip

Both .zip (what CI systems produce) and .tgz (what testfile archive pack produces) work, and runs that already exist locally are skipped, so repeated imports are safe.

Sharing through a bucket

Independent of the CI system, a pipeline can push its run to S3 and developers can pull it:

testfile s3 push s3://my-bucket/testfile-runs   # in the pipeline
testfile s3 list s3://my-bucket/testfile-runs   # locally
testfile s3 pull s3://my-bucket/testfile-runs

This uses the aws CLI, so it works with any S3-compatible endpoint the CLI is configured for (AWS_ENDPOINT_URL), including MinIO and Cloudflare R2. GCS and Azure have no dedicated backend yet; archive pack plus that provider’s own upload command achieves the same in two lines.