VyOS image build workflow
Workflow parameters
The workflow has the following parameters:
Repository URLs:
- debian_mirror
- debian_security_mirror
- vyos_mirror
The motivation for making repository URLs workflow arguments
is that LTS images are built from repository snapshots
to ensure they can be built reproducibly in the future.
Release information:
- build_by (e.g., "VyOS, inc.")
- version (e.g., 1.4.1)
- flavor (e.g., generic)
Additional parameters
- _bucket — the URL of the S3 bucket where artifacts are uploaded.
Mapping between versions and branches
The correct branch of vyos-build to build a release from
should be automatically inferred from the version number:
- 1.3.x — equuleus
- 1.4.x — sagitta
- 1.5.x — circinus
Fetch release flavor definitions
VyOS release flavors are TOML files that define how the image should be built
(image formats, custom packages, scripts for additional build steps...)
LTS release flavors are kept in this repository: https://github.com/VyOS-Networks/release-flavors/
Put the build scripts and release flavors together
Clone the build scripts repository: https://github.com/VyOS-Networks/vyos-build
Then copy all files from release-flavors to data/build-flavors in vyos-build.
Build the image
docker run --rm -it --privileged -v $(pwd):/vyos -v /dev:/dev -w /vyos vyos/vyos-build:$BRANCH bash sudo ./build-vyos-image --debian-mirror $DEBIAN_MIRROR \ --debian-security-mirror $DEBIAN_SECURITY_MIRROR \ --pbuilder-debian-mirror $DEBIAN_MIRROR \ --build-type $BUILD_TYPE --version $VERSION \ --build-by $BUILD_BY \ $FLAVOR
Upload the artifacts
Image build produces a file named build/manifest.json.
Its artifacts field contains a list of artifacts file names, relative to build/.
"artifacts": [ "vyos-1.4.1-generic-amd64.iso" ]
To prevent users from inferring URLs of image flavors they aren't entitled to,
we insert a random UUID in the path: s3://$BUCKET/$VERSION/$UUID/$FLAVOR
Most of it is similar to https://github.com/VyOS-Networks/vyos-reusable-workflows/blob/main/.github/workflows/build-image.yml
I wonder if it's feasible to make a completely reusable image build workflow, separate from upload.
So that the workflow for release builds will be like:
Fetch build flavors for LTS
Run the reusable build workflow
Run an upload workflow