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