This commit consolidates mkimage.sh scripts into a unified SD card image
creation tool that works for all boards. It needs a bootloader an $ARCH
rootfs.squashfs image and a genimage.cfg.in template.
- Detects build directories from `O=` environment variable or `output/`
- Sources `.config` to discover Buildroot paths
- Uses Buildroot's `support/scripts/genimage.sh` when available
- Automatically generates `.bmap` files if `bmaptool` is available
- Fallback to direct `genimage` invocation if wrapper not found
See the online instructions for usage.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With the additional support for RPi3, including Zero 2W, this commit renames
all relevant directories and Config.In options to match.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This will fix#1106, in time, but only allows manual trigger for now,
needs more test and verification
utils/kernel-upgrade.sh at least automate all the manual manual processes
for upgrading the kernel.
Addresses disk space issues in GitHub Actions for generic x86_64 builds
by removing unused tools (Android SDK, .NET, Docker images, etc.) before
the build starts. This frees up ~30GB of space.
Fixes#1210
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
With all jobs now depending on check-trigger we can do the evaluations
there and set some variables that can be reused later.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Here we use a check-trigger job that all the others depend on, which
should prevent duplicate workflows starting a bit more elegantly than
killing one of them with the concurrency checker.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This is currently a standalone workflow that needs manual trigger via
workflow_dispatch, but the end goal here is to chain it to the release
job.
Signed-off-by: Richard Alpe <richard@bit42.se>
Add concurrency control to trigger workflow to cancel in-progress builds
when new events (like adding ci:main label) occur on the same PR. This
prevents resource waste from duplicate builds and handles the common
workflow where developers add the ci:main label after PR creation.
Fixes#1154
It should be possible to create test reports manually, so logically
the GitHub workflow should call a make rule in test.mk
Untested: branding, or any case where Infix is used as a BR2_EXTERNAL
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This branch can be used to test push events which is especially
useful when working on the CI infrastructure.
Signed-off-by: Richard Alpe <richard@bit42.se>
There are 2 main reasons for this:
1) It's almost impossible to write complex logical expressions in GH
workflows. I wanted to pass "" as flavor when not building _minimal.
So that the end target string would become TARGET + FLAVOR where
FLAVOR is empty, making it x86_64 for example.
As it turns out "" is false in GH workflow logical expressions, this
in conjunction with the limitations the interpreter has made it hard
to actually write sane expressions in the "with:" variables when
calling downstream jobs via workflow calls.
Here's an example of what I was trying to do and could not:
with:
flavor: ${{ (
github.event_name == 'pull_request' &&
contains(github.event.pull_request.labels.*.name, 'ci:main')
) && '' || '_minimal' }}
As '' is false, the first sets of expressions always evaluates to
false making the string "_minimal". I tried bracing this in various
ways and to use "null" or various JSON objects, all in vain.
2) It reduces complexity instead of adding additional.
Signed-off-by: Richard Alpe <richard@bit42.se>
- custom cover page for pdf
- Center and resize logo
- Place slogan just below logo
- Ensure all text on cover page is in matching grey
Please note, the mkdocs-to-pdf plugin works, but it has a bug in the
enumeration of sections. We may need to fork it to make it work the
way users expect.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
The Python tool 'mike'[1] helps manage multiple versions of MkDocs-powered
documentation. Only required when building the kernelkit.org site docs!
For each new tag, that steps year or month, a new version of is created of
the documentation, in a separate sub-directory on the gh-pages branch.
Strategy - Version Grouping with Early Publishing:
- Extract YEAR.MONTH from tag
E.g., v25.06.0-beta1, v25.06.0-rc1, v25.06.0, v25.06.1 → become version 25.06
- From first pre-release onwards:
- v25.06.0-beta1 → creates docs version 25.06
- v25.06.0-rc1 → updates docs version 25.06
- v25.06.0 (GA) → updates docs version 25.06
- v25.06.1 (patch) → updates docs version 25.06
- New major/minor series:
- v25.07.0-beta1 → creates new docs version 25.07
Benefits:
- Users get docs as soon as beta/rc is available
- Patches update existing docs (logical since patches rarely change docs significantly)
- Clean version grouping by YEAR.MONTH
- Mike handles create vs update automatically
[1]: https://github.com/jimporter/mike
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Mattias Walström