Appearance
Builds
The Hub builds your apps for you. Point it at a Git repository (or a registry image) and Pantacor's build runners turn it into a signed pvr export: the container, ready to add to a device's state, for every architecture you ask for. Nothing runs on your machine or your CI runner; they only submit the build and collect the result.
Development preview. Builds run on the stage Hub (
https://hub.stage.pantahub.com, APIhttps://api.stage.pantahub.com). Executions are recorded as unbilled development runs; nothing is charged, but your plan's build minutes are enforced (see Limits).
What can be built
| Source | What the runner does |
|---|---|
| A repository with a Dockerfile | Builds the image with BuildKit and packages it as a Pantavisor container. |
A repository with a pvpkg.json | Follows the manifest: its Dockerfile, or a Yocto (kas) or Buildroot recipe that builds the root filesystem, then packages it with the repository's pvpkg/ overlay. |
A registry image, pinned by sha256 digest | Imports the image and packages it. |
| meta-pantavisor, as an image base | Builds the BSP, core containers and partition layout of a machine with kas, once per machine and version. |
| Flashable device images | Customises an image base (or a factory image) for one of your signing identities, adds your app builds and an OEM configuration part, and writes one .img.xz per policy. |
Preparing a repository explains each repository layout; Flashable device images the image builds.
From a container to a device
Builds chain into each other; each step is signed and checked, as a device would check it:
| Step | Build | Gives | Signed with |
|---|---|---|---|
| 1. Your app | git or registry build | <app>.pvrexport.tgz | the identity's OEM key (<identity>-oem), or pvr's developer key |
| 2. The OEM part (optional) | added to an app or image build | <identity>/<policy>.config (Hub, join token, …) | the identity's platform key |
| 3a. A running device | none: put the export on it | a new revision | — |
| 3b. A new device | image base → factory → images | <identity>-<policy>.img.xz to flash | BSP and core containers: the platform key; apps: as built in step 1 |
Signing identities explains which key signs what and how the device checks it.
Three ways to start a build
- Web UI — the Builds page: start pipelines, follow logs, retry, download exports.
- pvr —
pvr build start|status|logs|downloadfrom a terminal or any script. - GitHub Actions — a workflow step that submits the build of the pushed commit, streams its log into the job and keeps the exports as workflow artifacts.
All three use the same API and see the same builds: a build started from GitHub shows up on the Builds page, and pvr can download its export.
How a build runs
- Admission. The request names a source (repository and ref, or image), a project, the architectures and a time limit. The Hub resolves a branch to its commit at once, so the build always uses one exact commit, even if the branch moves while it waits.
- Fetch. A runner claims the build and fetches that commit; a private repository with the account's git secret.
- Build. In its own BuildKit builder, isolated from other builds: the Dockerfile, or the Yocto/Buildroot recipe.
- Package. pvr turns the image into a Pantavisor container and lays the repository's
pvpkg/folder over it. - Sign. The export is signed: with the account's signing key when the build names one, else with pvr's public developer key (details).
- Artifact. The export (
<app>.pvrexport.tgz) is uploaded to the account's objects with its sha256. Downloads are checked against it.
Pipelines: several architectures at once
Ask for several architectures (amd64, arm64, arm32v6) and the build is a pipeline: one build per architecture, run in parallel, each with its own log, export and status. The pipeline succeeds when all of them do.
Statuses
| Status | Meaning |
|---|---|
queued | Admitted, waiting for a runner. |
running | A runner is working on it; the current stage shows next to it. |
succeeded | The export is ready to download. |
failed | A stage failed; the log says which and why. |
cancelled | Cancelled by you (or by the workflow that started it). |
timed_out | It ran past its time limit. |
A finished build can be retried: the same request again, as a new build. A retry of a tag builds the tag's commit, and is refused if the tag has moved since; anything else rebuilds the same commit.
Limits
| Time limit per architecture | Git builds 1 s – 4 h (14400 s); registry images 1 s – 1 h. Yocto and Buildroot need minutes to hours, Dockerfiles usually minutes. |
| Active builds | 8 queued or running per account; each architecture of a pipeline counts. |
| Build minutes | Counted per calendar month (UTC) from the measured run time of your builds, each architecture of a pipeline included; the dashboard shows the month's use. Once the month's minutes are used, new builds and retries are refused until the month ends; builds already running finish. |
| Sources | HTTPS GitHub and GitLab repositories; registry images pinned by sha256 digest. |
Versions
The export's version comes from pvpkg.json's version. Without one, a build of a tag is versioned with the tag's name (v1.2.0), and any other build with 0.0.0-g<commit>, like git describe. A version in the manifest built from a branch also gets -g<commit> appended.