* Use anonymous Docker volume as build output
Use anonymous Docker volumes as build output. This makes sure
every build is using a clean output directory.
This reverts commit ff07728fa3bb6b06e2c05a8134213a5830244259.
Removing the .git file from the git submodule is problematic when
updating buildroot: Files deleted stay present in the buildroot
directory (since their origin is no longer known).
The workaround has been introduced to allow building non-git submodule
releases (rel-6) on the same runners. Since rel-7 uses git submodule and
we stay with git submodule for the forseeable future, remove this work
around.
* Add AArch64/ARM64 EFI boot support (for QEMU and some boards)
* Allow GRUB to load cmdline.txt-like
* Enable qcow2/vmdk disk images
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Rename Home Assistant Amber to Yellow
Rename the board from "amber" to "yellow" as Home Assistant Yellow is
the official name now.
* Add Home Assistant Yellow to the build matrix
Make sure to overwrite existing files on upload. This allows to trigger
rebuilds and have the latest builds on the os-builds server.
Note: When using GitHub Actions, the release/ directory is cleared at
the beginning (by the checkout action, which has the clean option set
by default which also causes files in .gitignore to be deleted).
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.
It seems that the release drafter filters commits which have been made
before the last release has been made. If the last release is a
unrelated stable release, this clears the full changelog for the next
major release. It seems `filter-by-commitish` should prevent that.
While at it, also set `commitish` to be dev (which is the default, but
being explicit certainly doesn't hurt).
* 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
