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
* 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>
* 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
