build-one: add firmware_ref input for cross-repo bisect#94
Merged
Conversation
When investigating a regression that lives in OpenIPC/firmware (or its
referenced packages like hisilicon-opensdk) but only manifests in a
builder build, you previously had to either roll firmware master back
or fork builder.sh manually. Adds a clean way:
gh workflow run build-one.yml -f platform=hi3516ev200_fpv \
-f firmware_ref=<sha-or-tag-or-branch>
The workflow exports OPENIPC_FW_REV as env, which builder.sh now
honours: when set, it does a full clone (not --depth=1) and checks
out the requested ref before invoking the firmware build. When unset,
behaviour is unchanged (shallow clone of master HEAD).
Immediate motivation: bisect the +180 KB rootfs growth in
hi3516ev200_fpv between 2026-05-08 (5016 KB) and 2026-05-24 (5196 KB,
76 KB over partition limit). Per kaeru
'hi3516ev200-ev300-fpv-rootfs-size-overflow-2026-05-24'. Suspect is
recent hisilicon-opensdk bumps that brought in source-built sensor
drivers for ev200; bisect across firmware commits varying
HISILICON_OPENSDK_VERSION will pinpoint which bump pushed us past
the 5120 KB limit.
Generally useful long after this specific incident:
- Reproducing user-reported regressions at a specific firmware tag.
- Locking builds to a known-good firmware revision when builder is
ahead of firmware.
- Future cross-repo bisects of any kind.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a clean mechanism to pin OpenIPC/firmware to a specific ref (SHA / tag / branch) when running build-one.yml. Two-file change.
What's new
firmware_refonbuild-one.yml.OPENIPC_FW_REVenv to the Build firmware step.builder.shhonours$OPENIPC_FW_REV: when set, does a full clone (not--depth=1) andgit checkoutto the requested ref. When unset, behaviour is unchanged (shallow clone of master HEAD).Immediate motivation
Bisect the +180 KB rootfs growth in
hi3516ev200_fpvbetween 2026-05-08 (5016 KB) and 2026-05-24 (5196 KB, 76 KB over the 5120 KB partition limit). The first builder cron under the new mirror code surfaced this as a real content regression; suspect is recenthisilicon-opensdkbumps that brought in source-built sensor drivers for ev200, but no single commit accounts for the full growth. Bisect acrossHISILICON_OPENSDK_VERSIONvalues via this input will pinpoint which bump pushed us over.See kaeru note
hi3516ev200-ev300-fpv-rootfs-size-overflow-2026-05-24for the full investigation.Generally useful long after this incident
Test plan
gh workflow run build-one.yml -f platform=hi3516ev200_fpv -f firmware_ref=7fc6cda4(firmware tip ~3 weeks ago) → builder.sh logsDownloading Firmware @ 7fc6cda4and the build proceeds at that ref.firmware_ref→ behaviour unchanged (shallow clone of master HEAD).🤖 Generated with Claude Code