Link Search Menu Expand Document
Source on GitLab

VOXL SDK Build Pipeline

Table of contents

  1. Overview
  2. What’s in the Tarball
  3. Release Build Workflow
    1. 1. Audit the package set
    2. 2. Tag every package, in dependency order
    3. 3. Tag voxl-suite
    4. 4. Assemble the platform tarball: make-sdk-release.sh
    5. 5. Test, finalize, publish
  4. Nightly and Staging Builds
  5. Related Pages

Overview

This page shows how VOXL SDK releases are actually built. The tooling that drives all of it is open source and lives in the publishing-tools repository. The whole pipeline, end to end:

 sdk_csvs/sdk-X.Y.Z.csv                 the release manifest: every package + version
         │
         ▼
 release-sdk.sh ── safety checks ──►  git tag sdk-X.Y.Z on every repo,
         │                            pushed in dependency order
         ▼
 GitLab CI builds each package  ──►  voxl-packages.modalai.com  sdk-x.y section
         │
         ▼
 voxl-suite tagged                    pins the exact version of every package
         │
         ▼
 make-sdk-release.sh            ──►  voxl2_SDK_X.Y.Z.tar.gz   (one per platform)
         │
         ▼
 flash + test on hardware  ──►  final tag  ──►  downloads.modalai.com

This page covers the mechanics. For the surrounding process — versioning, change control, release testing, traceability — see Configuration Management.

What’s in the Tarball

An SDK build for a platform is a single archive that brings a board to a known software configuration:

voxl2_SDK_1.7.0/
├── install.sh          one-command SDK install to a connected board
├── README.md
├── system-image/       the flashable base OS image
├── voxl-suite/         every .deb package in the release + offline-install.sh
├── edgetx/             EdgeTX payload (voxl2 and voxl2-mini)
└── misc/

The publishing-tools repository is organized by platform:

DirectoryPlatformsStatus
qrb5165/VOXL 2, VOXL 2 Mini, ubun2.0-multiactive
qcs6490/QCS6490-based boardsactive
apq8096/VOXL (original)deprecated, kept for reference

Release Build Workflow

A stable SDK release is driven by a release manager working through the tools in the repository’s other-tools/ directory, in this order:

1. Audit the package set

Each SDK release is defined by a CSV listing every package and its intended version, kept under other-tools/sdk_csvs/ (one file per release). The release manager runs release-sdk.sh in test mode against it:

cd other-tools
./release-sdk.sh --file sdk_csvs/sdk-1.7.0.csv --test

The tool clones every listed project and runs safety checks — verifying that each repository’s state matches the planned version, and flagging things like commits pushed to master after a code freeze. The audit repeats until the manifest and the repositories agree.

2. Tag every package, in dependency order

Once the package set is confirmed, the same tool applies an sdk-x.y.z Git tag to every repository — pushed in dependency order (computed by build-order.py) so each package’s CI build finishes before anything that depends on it starts. Each tag triggers that package’s GitLab CI pipeline, which compiles it inside its version-controlled Docker build environment and publishes the Debian package into the release’s sdk-x.y repository section. Build progress across all packages is watched on the CI status page.

3. Tag voxl-suite

With every package built, the voxl-suite meta package is tagged. It pins the exact version of every package in the release, and the SDK release takes its version number from it. The first tag is a beta (e.g. sdk-1.7.0-beta1); the final tag comes only after the beta installers pass testing.

4. Assemble the platform tarball: make-sdk-release.sh

Each platform’s SDK installer is assembled by that platform directory’s make-sdk-release.sh. Run with no arguments it is fully interactive — it walks the release manager through every choice with menus, then downloads and packs everything. A typical session (output abridged):

$ cd qrb5165
$ ./make-sdk-release.sh

━━━ Platform ━━━
1) voxl2
2) voxl2-mini
3) ubun2.0-multi
Selection: 1
  ✔ voxl2

━━━ System Image Bucket ━━━
1) release
2) candidate
3) nightlie
Selection: 1

━━━ System Image ━━━
14 images available:

   1) 1.7.8-M0054-14.1a-perf.tar.gz
      ...
  14) 1.8.06-M0054-14.1a-perf.tar.gz

Image number (ENTER = newest, or type text to search all): 14
  ✔ 1.8.06-M0054-14.1a-perf.tar.gz

━━━ voxl-suite Version ━━━
Available repos:
1) dev
2) sdk-1.5
3) sdk-1.6
4) sdk-1.7
5) staging
Selection: 4
  ✔ sdk-1.7

----Selecting EdgeTX payload----
Select an EdgeTX release to include:
1) edgetx-v2.9.4-modalai.tar.gz
2) edgetx-v2.11.2-modalai.tar.gz
Selection: 2

━━━ Release Version ━━━
The 'voxl2_SDK_' prefix is added automatically, enter the version only:

  ✔ 1.7.0          stable release
  ✔ 1.7.0-alpha1   alpha release
  ✔ 1.7.0-beta0    beta release
  ✘ SDK_1.7.0      no prefixes!

Version: 1.7.0
  ✔ voxl2_SDK_1.7.0.tar.gz

━━━ Release Summary ━━━
  Platform       voxl2
  System image   1.8.06-M0054-14.1a-perf.tar.gz
  voxl-suite     sdk-1.7
  EdgeTX         edgetx-v2.11.2-modalai.tar.gz
  Output         voxl2_SDK_1.7.0.tar.gz

Upload automatically when the build finishes? [Y/n]: y
Proceed with build? [Y/n]: y

----Setting up folder structure----
----Getting System Image----
----Getting SDK----
----Copying EdgeTX----
----Tarring (be patient)----

After the prompts, the script downloads the selected system image, mirrors the full package set from the chosen repository section of voxl-packages.modalai.com, bundles the install scripts and EdgeTX payload, and tars the folder shown in What’s in the Tarball. This is repeated for each platform.

5. Test, finalize, publish

Beta tarballs are flashed and tested on hardware first (release regression testing). Once they pass, the final voxl-suite tag is applied and step 4 is repeated with the final version string. Released installers are published for end users at downloads.modalai.com, which handles the license acknowledgment required before download.

Release notes are generated by two tools: generate-change-table.sh diffs the new release’s CSV against the previous one into a Markdown version table, and the sdk-changelog-generator exports a detailed changelog aggregated from every package. Both feed the published release notes.

Nightly and Staging Builds

The same assembly tooling runs unattended every night, driven by GitLab CI scheduled pipelines defined in the repository’s .gitlab-ci.yml. There are four scheduled jobs, one per platform target:

  • voxl2_nightly
  • voxl2_mini_nightly
  • ubun2.0-multi_nightly
  • qcs6490_nightly

Each job calls the platform’s make-sdk-release.sh in non-interactive mode — every menu above answered automatically — then stores the result for internal testing. A schedule variable selects one of two build flavors:

FlavorSystem imagePackagesPurpose
nightlylatest nightly system image builddev repository (per-commit CI output)exercises the newest everything; surfaces integration breakage within a day of a change landing
stagingpinned release-candidate system imagestaging repositoryexercises the stabilized package set as it converges on the next release

Nightly tarballs are named with a datestamp (e.g. voxl2_SDK_nightly_20260803...tar.gz) rather than a version number, making them immediately distinguishable from releases. They are built for internal daily testing on hardware, as described in Configuration Management, and are available to customers upon request.

Nightly builds are assembled from development-branch packages and are not release-tested. Fielded systems should run stable SDK releases, which go through the full regression and flight-test cycle before publication.