068b861edc
* create init resize for pi * wip * defer to OS_ARCH env var * enable password auth in live image * use correct live image path * reorder dependencies * add grub-common as dependency * add more depends * reorder grub * include systemd-resolved * misc fixes * remove grub from dependencies * imports * ssh and raspi builds * fix resolvectl * generate snake-oil on install * update raspi build process * script fixes * fix resize and config * add psmisc * new workflows * include img * pass through OS_ARCH env var * require OS_ARCH * allow dispatching production builds * configurable environment * pass through OS_ARCH on compat build * fix syntax error * crossbuild dependencies * include libavahi-client for cross builds * reorder add-arch * add ports * switch existing repos to amd64 * explicitly install libc6 * add more bullshit * fix some errors * use ignored shlibs * remove ubuntu ports * platform deb * Update depends * Update startos-iso.yaml * Update startos-iso.yaml * require pi-beep * add bios boot, fix environment * Update startos-iso.yaml * inline deb * Update startos-iso.yaml * allow ssh password auth in live build * sync hostname on livecd * require curl
This folder contains GitHub Actions workflows for building the project
backend
Runs: manually (on: workflow_dispatch) or called by product-pipeline (on: workflow_call)
This workflow uses the actions and docker/setup-buildx-action@v1 to prepare the environment for aarch64 cross complilation using docker buildx. When execution of aarch64 containers is required the action docker/setup-qemu-action@v1 is added. A matrix-strategy has been used to build for both x86_64 and aarch64 platforms in parallel.
Running unittests
Unittests are run using cargo-nextest. First the sources are (cross-)compiled and archived. The archive is then run on the correct platform.
frontend
Runs: manually (on: workflow_dispatch) or called by product-pipeline (on: workflow_call)
This workflow builds the frontends.
product
Runs: when a pull request targets the master or next branch and when a change to the master or next branch is made
This workflow builds everything, re-using the backend and frontend workflows.
The download and extraction order of artifacts is relevant to make, as it checks the file timestamps to decide which targets need to be executed.
Result: eos.img
a note on uploading artifacts
Artifacts are used to share data between jobs. File permissions are not maintained during artifact upload. Where file permissions are relevant, the workaround using tar has been used. See (here)[https://github.com/actions/upload-artifact#maintaining-file-permissions-and-case-sensitive-files].