Skip to content
Console
Menu

Queues

Workflows

Getting Started

Authentication

KV Store

Builds quickstart

A commit to an image, followed from the management API.

A build starts when you deploy a commit, and is then read by id. There is nothing to configure in between: the build answers with its state while it runs, and with its image digest when it is done.

Today this runs on the management API

Builds run on the management API: a deploy starts one, and GET /v1/builds and GET /v1/deployments/builds/{id} read them. Creating a build directly, cancelling one and reading SBOM and provenance digests belong to the builds collection of the API reference, which api.sylphx.com does not serve.

#1. Start the build

A deploy builds the commit at the tip of the service's branch:

Shell
sylphx api POST /v1/projects/$PROJECT_ID/deploy -d '{"envType":"production","force":true}'

A push to the branch does the same, so most builds start without a call.

#2. List the builds

The list is the history of builds for the organization, newest first. Pass projectId to read one project's:

sylphx api GET "/v1/builds?projectId=$PROJECT_ID"

Each entry has an id, the gitSha and gitBranch it built, its status, and when it started.

#3. Follow one to its image

Shell
sylphx api GET /v1/deployments/builds/$BUILD_ID
FieldTypeWhat it is
statusstringWhere the build is in its life.
gitobjectThe branch, the commit sha and the commit message.
image.digeststringThe content digest of the image the build produced.
timingobjectWhen it was created, started and finished, and how long it took.
diagnosticsobjectWhy a build failed, was cancelled, or was superseded by a newer commit.
build.logsAvailablebooleanWhether the build log can be read.

A build is immutable once it has ended, so reading it later tells you what ran, not what would run now. The environment's deployment history, which names the builds each deploy used, is GET /v1/deployments/projects/$ENV_ID/deployments.

#Next