* Use alternative environment for release build bump
By using a separate environment, we can postpone the bump in the version
repository by adding a requirement for approval. Dev version will use
default (empty string) environment which doesn't have any constraints.
* Update build step name - it's not always dev build anymore
* Use dynamic environment name for beta/stable channels
* Fix extraction of OVA image artifact in test step
If the test image is obtained from an artifact instead of downloading,
its name contains the version as well, in that case we still need to use
wildcard expansion.
* uncompress qcow2 to a stable filename
* Create foundation for Labgrid-based OS tests
Add foundation for Labgrid-based tests of OS builds. Currently uses just
the QEMU driver, which starts a virtual machine with pristine OS, and
generates few log reports which are saved as build artifacts.
Workflow is currently triggered either manually by specifying an OS
version, or by OS build job, which now saves an artifact of the OVA
image. This allows for some modularity. If we eventually add the
possibility to run builds on PRs, we could also add the workflow_call
trigger and turn the workflow into a reusable one.
TBD (in future PRs): some meaningful tests and possibility to test on
real hardware (either local or distributed).
* Apply suggestions from @agners
Co-authored-by: Stefan Agner <stefan@agner.ch>
* Wrap test command in a script, create venv for local tests
* Make shellcheck happy
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
Respect quotes in the meta file. While at it, simplify version
validation as well.
Make sure development version is correctly set at build time.
While at it also simplify version check.
* Adjust Home Assistant versioning to prepare for new release strategy
With OS 11 we'll create rc pre-releases which will get directly pushed
to the beta channel. In contrast, release builds will get directly
pushed to the stable channel.
Similar to Home Assistant Core we'll create bump commits for all stable
and beta releases. This makes sure that the source code matches the
built binaries for all releases.
The development build will get a generated version. To avoid issues
with the new rc builds the dev build version will get injected on source
level now.
* Apply suggestions from code review
Use a single workflow file for releases and dev builds. This avoids
duplication and enhances the release builds with some of the recent
improvements (e.g. shared build container).
It turns out that the way concurrency works in GitHub action doesn't
allow to queue up multiple pending jobs. As soon as a second job gets
pending, the previous pending jobs get cancelled. So this does not allow
to sequentially run all cache combine jobs as we hoped for.
Let's use a single download cache and per board build cache for now.
This combines all caches in a single cache to save space (assumption is
that quite some files are duplicated otherwise). With this we shouold
end up with 4 relevant cache files (build cache for each architecture
plus download cache).
Use more specific keys for GitHub Action caches to make sure we update
caches regularly. Also add board id to the downloads cache to get a
more specific cache file. This avoid redownloading large dependencies
of some boards.
* Determine git reference in prepare step
We can determin the git reference used once in the prepare step.
* Build HAOS builder in prepare step
Instead of building the build container multiple times, simply build it
once in the prepare step. This saves some GitHub Runner time (as we only
need to create the builder once).
* Drop per PR builds
Drop the per PR builds which are based on pull_request_target. These
make things more complicated with the recent changes requiring two
deployment approvals since we use the environment in for the prepare
and build job now. It will also interfere with future expansions.
We should consider readding the feature using `pull_request` and
subsequent `workflow_run` trigger, as suggested by
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/.
* Simplify board filter
* Initial commit of Home Assistant Green board support
* Add Home Assistant Green boot files
* HA Green board configs
* board/nabucasa: Unsupport rtc rk808
* Use odroid-m1 as Supervisor machine for now
* Green: linux: pmic: set set PWRON_LP_OFF_TIME 12s
* green: Update U-Boot to 2023.07.02
* green: supports usb boot
* green: uboot-boot.ush use rk3566-ha-green.dtb
* green: spinor supports uboot
* green: use U-Boot provided devtype as boot device type
* green: Fix polarity of power key
The power key is low active. Add patch to avoid accidential long press
being reported to user space.
* green: uboot: eeprom: add CONFIG_ENV_OVERWRITE
* green: uboot: eerprom: add mac read
* green: fix-cpufreq null issue
* green: board aliases ethernet0
* green: uboot mac set ethernet0
* green: uboot add serial-number read
* green: Update kernel 6.1.39
* green: add green to the build matrix
* green: fix 339d13 & 9b9416 can not boot from usb
* green: changfe sd mode, change led default state
* green: uboot add board.c to read eeprom info
* green: enable uboot to read eeprom info
* green: delete boot.scr read eeprom function
* green: change spl loader uboot order:sd-emmc-spi_nor
* green: serialnum change to 18 bytes
* green: Update kernel 6.1.43
* green: use hwrng support from ODROID-M1
* green: Use latest Rockchip BL31/DDR binaries
* change led_act polarity
* green: Disable watchdog
The watchdog on Green seems to not reliably reset the system. For now
disable the driver to avoid systemd making use of it.
* green: Update kernel 6.1.44
* green: Fix Supervisor Machine
Use odroid-m1 for now as Supervisor machine (used to download the
landing page).
* green: emmc use hs200 to increase speed
* green: use green as Supervisor machine
* green: Update kernel 6.1.45
* green: add Green to the kernel documentation
---------
Co-authored-by: Zhangqun Ming <north_sea@qq.com>
Co-authored-by: syan <syan.cham@gmail.com>
* Use hosted GitHub Action runners
Instead of using self-hosted runners use the hosted GitHub Action
runners. Officially the GitHub Action runners have a maximum of 14GB
free space available. However, a single Home Assistant OS build requires
up to 23GB (the ova board seems to require most because of the various
output image formats).
This PR adds some tricks to make use of the GitHub hosted GitHub Action
runners still, namely:
- Build and download cache is stored on /mnt which offers an additional
10GB of disk space
- Some tools/SDKs on the runner get removed from the root disk to free
up some disk space.
Other than that building on the hosted GitHub Action runners seems
straight forward. The build time is significantly longer (from ~30
minutes on the current AMD Ryzen 7950X build machine to 1 hours 30
minutes even with cache). But since we can build all boards in parallel
now, the overall build time will likely be shorted.
* Remove top-level release directory
The top-level release directory adds another copy of the images. This is
unnecessary for our release process now. Save the additional space and
time requirement. It comes with a slight downside for developers, but
also helps to save disk space on dev machines.
The chosen GitHub action sets MIME types correctly and allows glob
uploads. Also upload directly from the output directory. This way we can
remove the unnecessary copy to the release directory in the future.
* Add ODROID-M1 board support
* Add Rockchip kernel config for ODROID-M1
Kernel defconfig for Rockchip is based on Armbian kernel defconfig
from config/kernel/linux-rk3568-odroid-edge.config (git hash
95c829f9e664).
* Add U-Boot/Kernel patches
* Add Rockchip blob support
Add package which provides Rockchip TPL and ATF firmware binaries.
* Use latest U-Boot for ODROID-M1
* Fix Rockchip blob support
* Update defconfig
* Use GPT by default
* Create uboot partition to support non-recovery boot
* Enable eMMC boot in U-Boot SPL
* Drop unnecessary mmc device selection
Distro boot already activates the right mmc device. The extra selection
seems to actually cause problems for eMMC boot.
* Make sure driver for eMMC is built-in
* Use odroid-m1 as Supervisor machine
* Add ODROID-M1 to CI pipeline and issue template
* Bump to Linux 6.1.16
* Update config for Buildroot 2023.02
* Use Buildroot's version of the rtl8821cu package
Buildroot provides a newer driver for the RTL8821CU based chipsets
provided by https://github.com/morrownr/8821cu-20210118.
* Pass argument when verifying partition table
This also avoids running into a segmentation fault in the current
version of sgdisk.
* Remove obsolte GRUB2/NetworkManager patches
* Bump buildroot
* buildroot 90aa1a6daa...4832525e6c (4596):
> package/runc: add support for CGroup device permission updates
> package/network-manager: fix build with -Dmodem_manager=false
> package/dbus-broker: bump to release 33
> package/iptables: Allow to use iptables with nf_tables backend
> package/brcmfmac_sdio-firmware-rpi: bump to latest version
> package/linux-firmware: Deploy fewer Intel WiFi 22000 series variants
> package/linux-firmware: Add more Intel WiFi 22000 series variants
> package/linux-firmware: Add Broadcom BNX2 firmware
> package/rpi-firmware: bump version to 1.20230106
> Update for 2023.02-rc2
* Use Ubuntu 22.04 for CI checks
* Bump xe-guest-utilities to 7.33.0
* Remove unnecessary shellcheck ignore for xe-guest-utilities
* Address new buildroot check-packages issues
* Update outdated ui references in issue template
* Mention top right menu
* Remove health
* Remove health and fix directions
Co-authored-by: Stefan Agner <stefan@agner.ch>
* chore: Set permissions for GitHub actions
Restrict the GitHub token permissions only to the required ones; this way, even if the attackers will succeed in compromising your workflow, they won’t be able to do much.
* Remove global permissions which are set implicitly
With restrictive settings in the global GitHub Action permission settings
those permissions are given implicitly.
Co-authored-by: neilnaveen <42328488+neilnaveen@users.noreply.github.com>
Co-authored-by: Joakim Sørensen <hi@ludeeus.dev>
Co-authored-by: Stefan Agner <stefan@agner.ch>
