But you see - it's efficient if we add _our_ configuration layer with custom syntax to spawn a test-container-spawner with the right control port so that it can orchestrate the spawning of the environment and log the result to production-test-telemetry, and we NEED to have a dns-retry & dns-timeout parameter so our test-dns resolver has time to run its warm-up procedure.

And I want it all as a SaaS!

A CI system is more like a scheduler.

To make things simple: make is a build system, running make in a cron task is CI.

There is nothing special about tests, it is just a step in the build process that you may or may not have.

In my view, the CI system is supposed to run builds and tests in a standardized/reproducible environment (and to store logs/build artifacts).

This is useful because you get a single source of truth for "does that commit break the build" and eliminate implicit dependencies that might make builds work on one machine but not another.

But specifying dependencies between your build targets and/or sourcefiles, is turning that runner into a bad, incomplete reimplementation of make, which is what this post is complaining about AFAICT.

> a CI isn't supposed to be a build system?

No. "Continuous Integration" is the practice of frequently merging changes to main. In this sense, "integration" means to take my changes and combine them with other recent changes.

A build and test system like those described in this article is a way to make CI safe and fast. It's not CI itself, it's just the enabling automation: the pre-merge checks and the post-merge artefact creation.

A CI is really just a "serverless" application.