These boards support the rather ancient ARMv6 architecture only. We
officially stopped supporting them already two releases ago, its time to
say goodbye.
If a git submodule is converted to a regular git directory (e.g. when
moving from dev -> rel-6 branch), the directory is not properly cleaned
by the checkout action.
Remove the git submodule .git files which makes sure that git properly
reinitialize subdirectories, even if they have been a submodule before.
See also: https://github.com/actions/checkout/issues/624
Add buildroot utils/check-package check to the pr-checks.yml workflow.
It checks for common errors/mistakes when creating own buildroot
packages. Also fixed all warnings this utility output for our existing packages.
* Enable some useful kernel configurations
* Add xe-guest-utilities for better Xen support
Add guest utilities and make sure the Xen guest daemon gets started
when running under Xen virtualization.
* Avoid using tar when uploading dev builds
The GitHub action to upload the images to the os-builds server uses
tar before uploading. This creates unnecessary copies and takes a while.
Switch to a GitHub action which uploads the images using rsync instead.
* Drop buildroot from git repository
Manage buildroot in a separate git repository and use a git submodule
to include it into the HAOS source tree.
This makes it easier to manage changes to buildroot since it can be
managed by git. A buildroot fork repository is being maintained with
the changes we currently have. It makes the buildroot-patches unnecessary
and should make it easier to rebase and upstream changes to buildroot.
* Remove buildroot-patches
Now that buildroot changes are managed in the buildroot fork repository
there is no need to manage patches in a separate directory.
* Initialize git submodule if necessary
* Move build directory to root
This avoids conflict/local modification issues with the buildroot
git submodule.
Support OS releases (tags) with custom dev part (3rd group of the
release number). This allows to create tagged release candidates with
the form 6.0.rc1.
Virtual Disk images are often used on Windows and/or Mac platforms where
xz is not a widely known file ending and also not supported by dafault.
Use zip which is much better known.
Keep using xz for boards since those are not meant to be extracted by
users but directly used in Etcher. Also keep using xz for qcow2, since
qcow2 is mostly used on Linux platforms where xz is available by default
and zip usually needs an extra package.
* Bump dev channel after build
Bump version on dev channel automatically when building a dev branch
pre-release.
Co-authored-by: Joakim Sørensen <hi@ludeeus.dev>
HAOS builds add a lot of files and things get quickly messy. Use a
directory per build.
Also don't abort the complete build if a single board failed, we still
might be interested in the rest.
* Add development build version part to version number
Add third part in the version number to indicate development builds.
Generate a default version number based on the date, e.g.
"5.6.dev20201124".
* Add GitHub Action workflow for development builds
Add another GitHub workflow for development builds. Make it triggered
only for now. The version number is generated by the workflow and
passed to all builds to make sure all builds have the same development
build version.
* Add documentation
* Initial version of release workflow using GitHub Actions
Add release workflow using GitHub Actions to replace the current Azure
DevOps pipeline. Currently the same functionality is implemented. This
uses multiple builds in parallel to make better use of CPU resources.
Remove Azure DevOps pipeline.
* Add GitHub Actions workflow for pull-request checks
Lint Dockerfile and shell scripts when PRs are opened.
* Use multiple runners in parallel
Buildroot has stretches where CPU resources are not fully utilized.
Spawn multiple builds accross builders to increase load. Also sort them
by architecture to maximize ccache hit rate.
* Checkout before validate version
* Change titels to reflect official/new naming
* Use GitHub Actions to trigger Release Drafter
The Add-On is no longer developed and GitHub Actions is the recommended
way to use the Release Drafter
