Derivative Maker Automated CI Builder

Development
143

build targets:

  • Kicksecure ISO
    • Xfce
    • CLI
  • Kicksecure for VirtualBox
    • Xfce
    • CLI
  • Whonix ISO (future)
    • Xfce
    • CLI
  • Whonix for VirtualBox
    • Whonix-Gatway
      • Xfce
      • CLI
    • Whonix-Workstation
      • Xfce
      • CLI
  • Whonix Xfce for VirtualBox Windows Installer (building requires negligible time)

That’s ~ 10 build targets so far. (Currently - 2 because there is no Whonix ISO yet at time of writing.)

But building ISO CLI maybe makes limited sense anyhow. →

Maybe I could drop the CLI builds from the CI. That would half the number of build targets to 4 (or 5). It’s unlikely that that Xfce build would succeed but the CLI build would fail.

Then there is also ARM64 / UTM builds supported by derivative-maker. I’ve configured the CI for now to create ARM64 builds only and no AMD64 builds. This is because ARM64 builds are more likely to fail than AMD64 builds. There are few cases where the ARM64 build would succeed but the AMD64 build to fail. (Except for Tor Browser download.)

That makes sense now but will fail in the future when the CI would run automated tests of the VirtualBox VMs because at time of writing VirtualBox is available for AMD64 only.

If we created both, AMD64 + ARM64 builds, that would double the number from 4 (or 5) to 8 (or 10).

We could declare ARM64 not our problem. If someone wants to maintain an ARM64 or other architecture support, they should please run their own instance of the CI.

Where reasonable without increasing code complexity too much, I’ve already optimized the build process in so far that build steps that don’t need to be needlessly run over and over again are run once only. (Such as dependency installation, package creation and base raw image creation.) It could be optimized furhter in theory (have base images share more installed packages) but that would make derivative-maker more complex. Since there are few people already who can handle and/or are interested in build scripts, that is probably a bad idea.

I configured the CI to use developer-meta-files/usr/bin/dm-virtualbox-build-official at master · Kicksecure/developer-meta-files · GitHub. That is the script which I am using to create official builds. This I have done to avoid having to maintain build commands / targets separately for official builds versus CI builds.

That approach however isn’t compatible yet with:

  • A) running build targets concurrently on the same VPS runner, let alone
  • B) running build targets concurrently on separate VPS runners.

Next thing I could work on is A). In theory it should already work. All paths used during the build are already unique to the flavor and not shared. I just have to test it. But I have no idea how much time it would safe.

1 Like