Skip to content

How a build runs

What starts a build, what the queue does, what a build status means and where the log comes from.

A build is one run of the pipeline. It has a number, a status, a trigger, a log and, if it succeeded, a release.

What starts one#

A pushtrigger: push

To the tracked branch, with build on push enabled. GitHub sends one webhook and the build is queued.

The consoletrigger: manual

The build button. It builds the branch as it stands now, not the last commit a webhook reported.

Build on push#

With build on push off, the webhook is still received and still records the commit; it simply does not queue a build. Turn it off while a branch is unstable, and use the build button when you want one.

The queue#

One build at a time per source. The build button is unavailable while one is running.

A pending build shows its position in the queue, and the Flight page shows the queue alongside the source, so you can see whether you are waiting on your own build or on the machine.

Statuses#

StatusMeans
pendingqueued, with a position in the queue
runningclaimed by a build machine
succeededa release was written
failedit stopped, with an error and whatever log was captured

Reading a build#

The Flight page lists the fifty most recent builds, newest first. Each carries its number, status, what triggered it, the commit and subject it built, how long it took, and the version it published.

Opening one shows its log.

The log#

Captured from the build container, and truncated at 24 KiB. A build that produces more than that ends with a truncation marker.

The log viewer in the console can search, wrap, follow a running build and download the whole thing.

What happens between queue and release#

  1. Claim

    A build host claims the build. Claiming twice is refused, which is what keeps two hosts off the same build.

  2. Clone

    A shallow clone of the tracked branch. Git runs with a protocol allow-list on every invocation, not just the clone, because a submodule file is attacker-controlled and is read afterwards. Symlinks are disabled in the checkout entirely.

  3. Resolve the manifest

    Read and fully validated before a container starts. A manifest error therefore fails fast and costs no build time.

  4. Run

    The build command, in a container with no network and a wall-clock timeout.

  5. Collect

    Exactly one regular file has to match the output pattern. The collector refuses anything that is not a regular file inside the tree, so a symlink is not followed and published.

  6. Publish

    The artifact, the listing, the version, the checksum, the variable metadata and the dependency graph become a release.

How a build is contained

What the container can and cannot reach while your code runs in it.

Read on
CEagle documentation