fix(ci): Windows release ZIP root no longer wraps in release-staging/ (closes #92)#97
Merged
Merged
Conversation
Closes #92. The Windows branch of the `Stage release bundle` step in `.github/workflows/release.yml` ran: 7z a -tzip release-artifacts/uffs-windows-x64.zip "$STAGE_DIR/*" with `STAGE_DIR=release-staging/uffs-windows-x64`. 7z preserves the path prefix it's invoked with, so the resulting archive contained `release-staging/uffs-windows-x64/...` entries — i.e. unpacking gave a `release-staging/` wrapper folder around the expected `uffs-windows-x64/` directory. Mirror the non-Windows branch by `cd release-staging`-ing first, then archiving the unprefixed artifact-name. Both branches are now symmetric and the resulting archives unpack into a single `uffs-<target>/` directory at root. Verified: `actionlint .github/workflows/release.yml` clean on the changed region (exit 0; only pre-existing shellcheck info notes elsewhere in the file).
githubrobbi
added a commit
that referenced
this pull request
May 15, 2026
…lds (#254) * chore: development v0.5.99 - comprehensive testing complete [auto-commit] * fix(ci): repair rustup proxy AFTER cache restore on macOS release builds Release pipeline #97 (v0.5.98) failed on the aarch64-apple-darwin build with: error: unexpected argument 'build' found Usage: rustup-init[EXE] [OPTIONS] Stack backtrace: rustup_init::run_rustup_inner ... PR #245 already added a proxy-repair line ('rustup default ...') to the 'Install pinned nightly' step, and the in-step 'cargo --version' smoke check still passes — but the very next step, 'Swatinem/rust-cache', restores '~/.cargo/bin/' from a prior run's cache. On macos-latest that cache holds a poisoned 'cargo' symlink pointing at 'rustup-init' (the installer) rather than the toolchain proxy. The restore overwrites the freshly-repaired '~/.cargo/bin/cargo', and the subsequent 'cargo build' picks up the poisoned proxy and exits with the rustup-init backtrace before reaching any cargo subcommand. Empirical proof from the failing job (76219153458): 16:36:34Z cargo --version -> cargo 1.97.0-nightly (proxy healthy) 16:36:35Z Swatinem/rust-cache: restoring ~/.cargo/bin/ ... 16:36:54Z cargo build -> rustup-init backtrace (proxy poisoned) Fix: add a second proxy-repair step *after* the cache-restore step and *before* the build step. Re-running 'rustup default "$(rustup show active-toolchain | awk '{print $1}')"' rewrites the proxy binaries in '~/.cargo/bin' so the build resolves to the active toolchain's cargo even when the restored cache was poisoned. On the next successful run, 'Swatinem/rust-cache' saves a clean cache and the poison clears itself. Both 'release.yml::build-release-binaries' and 'release-cache-warm.yml::warm' get the same step (with matching commentary) — without the fix in the warm workflow, every macOS warm run would re-save the poisoned cache and perpetuate the regression. Step is gated on 'runner.os == macOS' so Linux and Windows legs (which do not exhibit this symptom) are unaffected. Pre-cache repair line is intentionally kept so the in-step 'cargo --version' smoke check still fails fast on a broken runner-image proxy.
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.
Closes #92.
Problem
uffs-windows-x64.zipproduced by the release workflow contains a wrapper directory: extracting givesrelease-staging/uffs-windows-x64/...instead of justuffs-windows-x64/.... The non-Windows branch of the same workflow already produces the expected layout.Root cause
In
.github/workflows/release.yml::Stage release bundle, the Windows branch ran:7z preserves the path prefix it's invoked with, so entries get stored as
release-staging/uffs-windows-x64/....The non-Windows branch already side-stepped this by
cd release-staging-ing first and archiving the bare${{ matrix.artifact-name }}.Fix
Mirror the non-Windows branch:
cd release-staging && 7z a -tzip ../release-artifacts/...zip uffs-windows-x64.Both branches are now symmetric.
Verification
actionlint .github/workflows/release.yml→ clean on the changed region (exit 0; only pre-existing info-level shellcheck notes elsewhere in the file).lint-pre-push(full smoke + xwin check, 66 s) green.Risk
Tiny. The change is a one-step
cdindirection in the bundling step. Failure mode (if any) would be archive-empty / archive-wrong-root, which is immediately visible from the workflow's ownls -la "release-artifacts/...zip"step. No code paths change; no end-user-visible binaries change.