ci: consolidate release workflows into a matrix; add arm64#169
Merged
Conversation
The two release workflows (release-arm32.yml and release-mips32.yml)
were near-identical 140-line files that differed only in toolchain
URL, cross-compile binary names, and asset suffix. Roll them into a
single release.yml that builds across a {arm32, mips32, arm64} matrix.
Adds arm64 as a new target. No OpenIPC-hosted aarch64 musl toolchain
exists yet, so the matrix entry fetches the well-known precompiled
aarch64-linux-musl-cross from musl.cc; swap this for an OpenIPC
tarball once one is published.
S3 dev-build publishing stays gated to arm32 (the historical canonical
binary on the legacy URL). Telegram success/failure notifications fire
for all three targets so the channel sees per-target build state.
Side fixes layered on top of the consolidation:
- The release / upload / telegram-success steps are now gated on
`steps.build.outcome == 'success'`. The old workflow ran the
release/upload steps after a `continue-on-error` build failure,
uploading whatever stale artifacts might be lying around and posting
a "success" telegram doc with a missing file.
- Drop the vestigial widgetii/ct-ng-builds release-fetch step — its
output was assigned to REL and only ever echoed.
pr-build-check.yml gets the same matrix treatment and now also tests
the arm64 target on every PR.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The first PR run of the matrix workflow hit a truncated download from musl.cc: gzip: stdin: unexpected end of file tar: Child returned status 1 The 100 MB aarch64-linux-musl-cross tarball is large enough that any CDN-edge hiccup truncates the wget|tar pipe. Two fixes: 1. Download to a file first (with --tries=3 --timeout=60) instead of piping straight into tar. wget's retry only resumes discrete-file downloads, not in-flight pipes. 2. Add a fallback URL on the more.musl.cc mirror so a stuck musl.cc edge node doesn't fail the whole release. Applied to both release.yml and pr-build-check.yml so PR runs exercise the same fetch path the release uses. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitHub Actions runners (Azure) can't reach musl.cc at all
("Connection timed out" against 216.82.192.11 from us-east). The
more.musl.cc fallback resolves to the same backend so it's no help.
Move the arm64 entry to Bootlin's well-maintained aarch64 musl
cross toolchain (https://toolchains.bootlin.com), which is reachable
from Azure and ships a 73 MB tarball (vs 100 MB on musl.cc). The
binary prefix changes to `aarch64-buildroot-linux-musl-gcc`.
Side cleanup: collapse the dual-URL fallback loop in the fetch step
to a single wget; `tar xf` (no compression flag) autodetects xz/bz2/gz
so different targets can ship different archive formats without
matrix-specific tar flags.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Follow-up to #168 (HiSilicon V5 + aarch64 support): adds CI publishing for the new arm64 target.
Why
The two release workflows (
release-arm32.yml,release-mips32.yml) were near-identical 140-line files that differed only in toolchain URL, cross-compile binary names, and asset suffix. Adding arm64 as a third copy-pasted file would have made the duplication worse.What
Roll both per-target release workflows into a single
release.ymlthat builds across an{arm32, mips32, arm64}matrix.Asset names preserved exactly:
ipctool,ipcinfo(no suffix, historical canonical names)ipctool-mips32,ipcinfo-mips32ipctool-arm64,ipcinfo-arm64(new)Toolchains:
toolchain.hisilicon-hi3516cv100from OpenIPC/firmware releasestoolchain.ingenic-t31from OpenIPC/firmware releasesaarch64-linux-musl-crossfrom musl.cc — no OpenIPC aarch64 musl toolchain is published yet; swap this for an OpenIPC-hosted tarball once one is available.S3 dev-build publishing stays gated to arm32 only (the historical canonical binary on the legacy dev URL). Telegram success/failure notifications fire for all three targets so the channel sees per-target build state.
pr-build-check.ymlgets the same matrix treatment and now also tests the arm64 target on every PR.Side fixes layered on top of the consolidation
continue-on-errorbuild failure, which would upload stale artifacts and post a "success" telegram doc with a missing file. They're now gated onsteps.build.outcome == 'success'.pozetroninc/github-action-get-latest-releasestep that queriedwidgetii/ct-ng-buildsonly to echo the version — its output was never used to influence the build.Test plan
release.ymlwill work on master.ipctool-releaseworkflow fires, produces 6 artifacts (ipctool,ipcinfo,ipctool-mips32,ipcinfo-mips32,ipctool-arm64,ipcinfo-arm64), and attaches them to thelatestrelease.🤖 Generated with Claude Code