4.3 KiB
4.3 KiB
Migration validation — 2026-10-10
Inspected the original Jenkinsfile, Dockerfile, downstream sqm-autorate-rust
workflows and package Makefile, Terraform runner definition, and live TheBeast
runner configuration before changing the repository.
Passed
- YAML parsing; TOML parsing;
sh -n; ShellCheck;git diff --check. - actionlint 1.7.12, excluding only its unsupported
builtin:checkoutaction syntax. The workflow uses the existingubuntu-latestlabel. Gitea's documentation and the existing downstream workflow confirm built-in checkout support. - Default matrix resolves six entries for stable 25.12.5 and oldstable 24.10.8.
targets=allran upstream target discovery inside the actual job image and resolved 194 entries. Empty/invalid targets fail. Every default base-image tag was read successfully from GHCR. - Docker Compose configuration accepted; Redis healthy with its named volume, AOF enabled and successful AOF writes. Service and bounded builder were provisioned on TheBeast without changing the runner configuration.
- Builder inspected: eight-CPU quota, 20 GiB memory/swap limit, one BuildKit worker step, 50 GiB layer GC budget. A second disposable job container with fresh Docker client configuration reused the existing daemon and builder.
- Dockerfile build checks completed. Two expected advisory warnings: mandatory
base-image arguments have no defaults, and Docker's secret-name heuristic
mistakes the public
SCCACHE_REDIS_KEY_PREFIXfor a secret. configuredDockerfile stage built for x86/64 on both OpenWrt releases. Pinned feeds select Rust 1.94.0 on 25.12.5 and 1.90.0 on 24.10.8. Both retainCONFIG_RUST_SCCACHE=ythrough defconfig and contain the explicit bootstrapbuild.ccache=sccachesetting with LLVM CI downloads disabled.- Actual OpenWrt make-variable expansion injects sccache into host and package compilation, despite unexporting an inherited wrapper.
- Real Cargo library compilation in Docker BuildKit: one Redis miss. A fresh runtime container using the Docker-network endpoint: one hit, zero misses.
- Recreated the newly provisioned Redis container using the same named volume; a fresh compiler container still recorded one hit, zero misses. No existing infrastructure containers were restarted.
- Same source/cache namespace with GNU versus musl target: first musl build missed; repetition hit. Rust 1.90.0 versus 1.91.0: first 1.91 build missed; repetition hit. All probes reported zero cache read/write errors.
- A disposable OpenWrt package used the real
Build/Compile/Cargohelper, SDK GCC/musl linker, OpenWrt LTO/optimization flags and a local Rust library dependency. It built successfully in two separate containers: one dependency miss, then one hit. The linked executable correctly remained non-cacheable. This used a prebuilt Rust 1.90 toolchain for the probe, not a freshly compiled SDK toolchain; it is not a full SDK/source-bootstrap acceptance result. - Retained
ci/verify-cache.shpassed its separate-container miss/hit checks against that prebuilt validation toolchain at the expected SDK rustc path. - Publication configuration checked: original Docker Hub namespace/tag format, verification before push, explicit publish input, temporary credential directory, no automatic publication trigger. No registry login or push was attempted.
Remaining acceptance
- Enable repository Actions and configure the two Docker Hub secrets. No runner configuration changes are required.
- Run a non-publishing Gitea dispatch for the full default matrix. Full Rust source bootstrap, complete SDK images, and live workflow scheduling have not been verified in this migration session.
- With explicit publication approval, run the publishing dispatch, pull the resulting tags and build the downstream OpenWrt package with the new image. Actual Docker Hub authorization and publication remain unverified.
- After acceptance, disable the old Jenkins job and remove
Jenkinsfile. It is deliberately retained until the replacement passes these checks.
Remote test logs and disposable probe sources are under
/tmp/openwrt-sdk-rust-migration in TheBeast's gitea-runner instance. The
Redis volume/service and BuildKit builder remain available for the replacement
pipeline; no cache volume or existing infrastructure was deleted.