repository update: select stable kernels from a config file

[igorpecovnik]

Stacked on #406 — review that first; this diff is only the stable/kernel part.

Problem

The stable/ branch of Copy operations never moved anything:

if [ -d "${INCOMING_PATH}/stable" ]; then     # guards on incoming/stable …
  COPY_UBOOT=false DRY_RUN=true                # … dry run …
  SELECT=':edge' SRC_DIR=incoming/nightly/debs-beta/   # … reads nightly …
  DST_DIR=/tmp/x scripts/copy-kernel-packages.sh      # … writes to /tmp/x

A stable dispatch reported success and ingested nothing.

Change

Wired for real, driven by a config file, because kernels are a selection rather than a sweep — there is one linux-image per (linuxfamily, branch), and only some belong in the repository.

config/repository-kernel-selection.conf:

KERNEL_SELECT="x86 arm64 bcm2711"   # uefi-x86, uefi-arm64, Raspberry Pi
INCLUDE_LIBC_DEV="true"
COPY_UBOOT="false"
UBOOT_SELECT=""

Seeded with the three kernels stable enough to carry between releases. linux-libc-dev travels with them; u-boot does not, since none of the three boot through Armbian's u-boot.

Gotcha worth knowing: the tokens are LINUXFAMILY values, not board or BOARDFAMILY names — uefi-x86 builds linuxfamily x86, uefi-arm64 builds arm64, and rpi4b builds bcm2711. The config documents this inline.

Verification

Ran the real script against the live image-info.json with a fixture directory:

file	outcome
linux-{image,dtb,headers,libc-dev}-current-x86	copied
linux-{image,dtb,headers,libc-dev}-edge-arm64	copied
linux-{image,dtb,headers,libc-dev}-current-bcm2711	copied
linux-{image,dtb}-current-rockchip64	left behind — not selected
linux-u-boot-rpi4b-current	left behind — COPY_UBOOT=false

A selected family/branch with no deb present is reported as MISSING: in the step summary and does not fail the run — that is the script's existing behaviour, and it matters because not every family builds every branch every week.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 544e5692-07bf-4864-aff6-6de4beed6974

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[igorpecovnik]

Added udoo with the complete artifact set, so the weekly update exercises the full path on one ordinary board.

KERNEL_SELECT="x86 arm64 bcm2711 imx6"   # + udoo
COPY_UBOOT="true"
UBOOT_SELECT="udoo"

udoo builds linuxfamily imx6 (branches current and edge), which is why the kernel token is imx6 and not udoo — same LINUXFAMILY-not-board gotcha as the others.

The u-boot switch needed care. UBOOT_SELECT is per board, and an empty value means every board, not none — the filter is skipped when empty. Turning COPY_UBOOT on without naming boards would have pulled the entire fleet's u-boot packages into the repository. It's called out in the config comment.

To confirm headers: they're always copied, no flag involved — the script does for p in linux-image linux-dtb linux-headers per selected pair. linux-libc-dev is the only optional one, and it's on.

Fixture run:

file	outcome
linux-{image,dtb,headers,libc-dev}-current-imx6	copied
linux-{image,dtb}-edge-imx6	copied
linux-u-boot-udoo-{current,edge}	copied
linux-image-current-rockchip64	left behind
linux-u-boot-{rpi4b,orangepi5}-current	left behind

[igorpecovnik]

Added the cubox-i bootloader:

UBOOT_SELECT="udoo cubox-i"

cubox-i is imx6 too, so it already receives the kernel selected by KERNEL_SELECT="… imx6" — adding its u-boot makes it the second complete, updatable board rather than a board getting a kernel with no matching bootloader.

Fixture run:

file	outcome
linux-u-boot-cubox-i-{current,edge}	copied
linux-u-boot-udoo-{current,edge}	copied
linux-u-boot-cubieboard	left behind
linux-u-boot-rpi4b-current	left behind

That leaves the imx6 family in this shape: udoo and cubox-i fully updatable (kernel + bootloader), while the remaining imx6 boards receive the shared family kernel without a u-boot update. Worth naming more boards in UBOOT_SELECT if you want them complete as well — it's a space-separated board[:branch] list.

[igorpecovnik]

Caught a gap while tracing the end-to-end path, fixed in the latest commit.

The kernel selection was inside case "$TARGET" under "stable/"). But on the weekly chain (armbian/ci#58) the packages are built first — uploading to incoming/stable/ — and then base-files runs and fires the repository update. So the dispatch payload says base-files/, the stable/ arm never matches, and the kernels would have sat in incoming untouched. Dead code on the only path that produces them.

Now it works like the generic block: unconditional, guarded on incoming/stable existing. incoming is a drop box — whatever is in it gets ingested, whoever rang the bell. The stable/ case arm is a documented no-op.

[igorpecovnik]

Gated under base-files/ as you suggested — better than the unconditional version I had, on both counts.

ingest_stable_kernels() { ... }   # config + copy-kernel-packages.sh

case "$TARGET" in
  "stable/")     ingest_stable_kernels || exit 1 ;;   # manual / unchained
  "base-files/") ingest_stable_kernels || exit 1 ;;   # the weekly chain's signal
  "cron/")       ... rsync as before ...

base-files/ is what the weekly chain actually dispatches, so this is an explicit gate that still fires on the path that produces the packages. Keeping the stable/ arm means a manual stable dispatch works too.

It also removes the cost of the unconditional version I flagged earlier: copy-kernel-packages.sh copies rather than moves and nothing drains incoming/stable/, so running on every dispatch meant the eight daily cron updates re-copied the same debs. Now the selection runs once per weekly chain.

The generic packages stay unconditional — they're moved, so whichever update sees them first ingests them exactly once, and they shouldn't have to wait for a specific pipeline.

Behaviour by target:

target	kernel selection	generic move	cron rsync
base-files/	✅	✅	—
stable/	✅	✅	—
cron/ (incl. empty payload)	—	✅	✅
nightly/, apps/, community/	—	✅	—

[igorpecovnik]

incoming/stable is now drained after a successful selection — copy what we carry, drop the rest.

# … selection loop, both debs and debs-beta …

ST_TOTAL=$(find "${INCOMING_PATH}/stable" -type f -name '*.deb' | wc -l)
echo "## Dropping incoming/stable (${ST_TOTAL} .deb, selected ones already copied)" >> "$GITHUB_STEP_SUMMARY"
case "${INCOMING_PATH}" in
  *"/armbian/openssh-server/storage"*) rm -rf "${INCOMING_PATH}/stable" ;;
  *) echo "::error::refusing to remove …"; return 1 ;;
esac

Three things that make it safe to be destructive here:

• Only on success. The rm is after the loop, and any copy-kernel-packages.sh failure returns first — nothing is dropped on the strength of a failed copy.
• Counted first. The .deb total goes to the step summary before deletion, so the run records what it discarded.
• Path-guarded, like the other destructive steps in this workflow. Verified: /armbian/openssh-server/storage/incoming proceeds, /home/igorp/oops and / are refused.

The trade-off, stated plainly: widening KERNEL_SELECT picks up the new families from next week's build, not from what was sitting in incoming — that's gone. Given the alternative was an unbounded directory that nothing had consumed since Aug 9, that seems the right way round.

[igorpecovnik]

Corrected: the generic packages are no longer swept on the cron/ path.

cron/ is the nightly repository — build-all.yml runs with nightlybuild_default: "yes", so its debs go to debs-beta. Ingesting the base-files drop box there pulled stable-side packages into a run that shouldn't carry them.

Both ingests are now functions called from the two stable-side targets only:

target	kernel selection	generic packages	cron rsync
base-files/	✅	✅	—
stable/	✅	✅	—
cron/	—	—	✅ (unchanged)
nightly/, apps/, community/	—	—	—

cron/ now behaves exactly as it did before this branch: rsync incoming/cron into storage, drop the source, nothing else.

The trade-off I flagged earlier stands, and is now yours by choice rather than by default: if the weekly chain's dispatch is ever lost, the generic packages wait in incoming/base-files/ until the next stable or base-files dispatch, instead of being picked up by the next cron update.