Ambient processes source files into artifacts and optionally delivers or deploys them relevant parties.

At a very high level, this means that there is a source tree with some files that are part of a project. In the typical case, the source tree has the source code for some software, but it may also be the source code for a web site, the configuration for one or more servers, or anything else that can be expressed as files.

At various times, the source gets processed in an automated way. This is triggered by something, such as a change to the source tree, time passing, manually, or something else. For a software project, the processing might mean compiling the source code into binary form or running some automated tests.

After the processing, there may be artifacts and these may be automatically delivered to one or more recipients, which means they’re published so they may be downloaded. The artifacts may also be automatically deployed on some computer that will make use of them. In a common software scenario, the deployed code will be used to run a web site or service.

Each project gets to specify, in some way, how the processing is done. For many existing CI systems, this is done using some form of file in the source tree. In the simplest form, this is a shell script that gets run, but a Makefile is common. The GitLab .gitlab-ci.yml file is also an example of this.

In contemporary systems, the processing is usually more or less linear. Even when parts are concurrent, they usually run on a single machine. For Ambient, the long-term goal is to allow the processing to be spread over wildly and widely separated machines that don’t know about each other and may lack a way to communicate directly. This makes everything more complicated and error prone, but allows collaboration without tight co-ordination or strong trust.