This allows for rudimentary image/partition size tracking between builds,
potentially this could be further extended with more useful information
about the build (TBD).
* Generate self-signed certificates for development
To simplify development generate a self-signed certificate on first
build. Also make sure that the self-signed certificate is being added
the RAUC keyring so that manual updates can be performed.
* Add self-signed certificat independent of deployment type
* Add a warning when building with self-signed certificate
This reverts commit 49f26c3d2e685e3f7e9135f8e10efaa6a40526df.
The steps is not valid in that context. Let's revert the commit to get a
green build first.
* Separate artifacts index update into separate workflow
* Apply suggestions from code review
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
---------
Co-authored-by: Jan Čermák <sairon@users.noreply.github.com>
If a reusable workflow is called from another workflow, the event_type
in the child workflow is still the same as parent's. This is a known
"feature": https://github.com/actions/runner/discussions/1884
Add a flag to inputs that has default value set to true. This is in turn
set only if the workflow is called from another one, chosing the correct
step for obtaining the OS image.
* Add test suite for Supervisor tests
* test_supervisor_is_updated should depend on test_update_supervisor
Co-authored-by: Stefan Agner <stefan@agner.ch>
---------
Co-authored-by: Stefan Agner <stefan@agner.ch>
Print the object cache statistics before uploading them to the action
cache. The action cache accesses all files, this makes the statistics
of files used during build not useful.
* Optimize build cache for dev builds
* Remove downloaded files cache, as it doesn't save that much time and
it can't fit into the repo cache limit, randomly causing eviction of
CC object cache for a single board.
* Limit saving of the object cache only to the dev branch, because
of the restrictions for the cache access limit us from effectively
using the cache for rc/main branches anyway.
* Adjust names of the steps a bit for clarity.
* Add printing of some cache stats
* Compare old ccache files' age to Makefile
* Maintain and upload artifacts index
Make the artifacts browsable by maintaining a list of builds. This keeps
it up-to-date even when deleting images from the object storage, and
minimizes queries to the object storage.
* Add favicon
* Apply suggestions from code review
Co-authored-by: Joakim Sørensen <joasoe@gmail.com>
* Move index update outside of the build Matrix
* Add error handling and styling
* Exclude index files
* Add cache flush
* Use separate prefix for indexes
This allows to filter by prefix when generating the main index. Since
the list-objects-v2 is limited to 1000 entries, this will be a bottle
neck soon. Separating indexes allows to support up to 1000 nightly
builds.
* Add missing backslash
* Use cp and fix index format
* Sync index.html as well
* Move OS artifacts index file to root directory
This is not really GitHub related, so it shouldn't live in there.
* Adjust URL for dev builds
---------
Co-authored-by: Joakim Sørensen <joasoe@gmail.com>
Automate bump of the rpi-imager-haos.json in the version repository on
stable release so we don't have to do it manually. Uses slightly
advanced jq magic to touch only the changed fields and keep the rest of
the JSON content intact.
* 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).
