Flight is the build service. It is not a site you visit: it is a tab on a project and a build runner that does the work.
Give it a public GitHub repository and a file called .ceagle-flight, and every push to the tracked
branch produces a release on Roost.
The one guide most people need: the manifest, the Makefile, the output path and the first build.
The pipeline#
A push arrives
GitHub sends one webhook to the console. Its signature is verified before the body is read, and it is routed by repository id.
Visibility is checked
Flight asks GitHub whether the repository is still public and still visible to the installation. A repository that has gone private stops building the moment the event lands.
A build is queued
One build at a time per source. Starting another while one is running answers
409.The repository is cloned
A shallow clone of the tracked branch, with a protocol allow-list and symlinks disabled.
The manifest is read and resolved
Every value is validated before anything runs. A manifest that does not resolve fails the build without starting a container.
The build command runs
Inside a container with no network, every capability dropped, a read-only root filesystem and a wall-clock timeout.
The artifact is collected
Exactly one file has to match the output pattern, and it has to be a regular file inside the tree.
A release is written
The artifact, the listing from the manifest, the version, the checksum and the dependency graph.
Two kinds of source#
A public GitHub repository, reached through the CEagle GitHub App, built and published on every push. For ASM/C projects and LibLoad libraries.
No repository and no build. You attach a finished file and a version number. For TI-BASIC projects.
A project has exactly one source, and which kind it gets follows from the project language. You do not choose it separately.
Public repositories only#
Flight builds public repositories and nothing else. The visibility is read from GitHub at connect time, again before every build, and again whenever GitHub reports a repository event.
The build container has no network and no credentials, so a private repository could not be cloned anyway. Refusing it early is what makes that honest rather than a confusing clone failure.
What the app can see, how an installation is bound to your account, and the single webhook.
What you control#
The listing, the build command, the output path, the timeout and the dependencies.
Whether a push starts a build, or only the console does.
Which branch is tracked. Pushes to any other branch are ignored.
What you do not control#
The build environment is fixed and identical for every build. There is no way to install a package, add an environment variable, reach the network, or change the image.
That is what makes a build reproducible from the repository alone, and it is why everything a build needs has to be either in the repository or already in the image.
What is on the machine and what is not.