You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #1502 / PR #1591, which made the two resource copies fail-closed. Two neighbouring steps in scripts/build-release.sh keep the old shape: they log and continue after producing nothing, so the build exits 0 and the gap is only visible downstream.
Where
scripts/build-release.sh:566-568 — when resolve_ghostty_share_dir fails, the else-arm logs Ghostty share resources not found; packaged shell integration may be degraded and the build goes on. A bundle with no Ghostty resources (no shell integration, no terminfo/78/xterm-ghostty) is produced with exit 0. Today verify-release-bundle.sh --structure-only (run by ci.yml on the next step, and by the release lane) catches it as Missing Ghostty resources directory, so the consequence is a false-green build step rather than a shipped bundle. Codex rated it Medium on fix(release): resource copies into the bundle fail the build instead of logging success #1591; declined there on the fence.
scripts/build-release.sh:576-581 — actool … 2>/dev/null || log_warning "Asset compilation had warnings". A failed compile leaves an app without Assets.car, logged as a warning. verify-release-bundle.sh does not assert Assets.car, so nothing downstream catches an iconless bundle.
What to decide
Whether an unresolved Ghostty share tree is ever a legitimate local state (a dev build without the Ghostty build cache) or always a broken release build. If the former, the flag that opts into a degraded bundle should be explicit, not the default.
A test in scripts/tests/test_build_release_copies.py (or a sibling) asserting the chosen behaviour for each step, red before the change
./scripts/build-release.sh --no-sign end to end followed by ./scripts/verify-release-bundle.sh --structure-only build/WorkSpaces.app, both result lines quoted
uv run --script scripts/validate-release-changes.py passes for the changed files
Follow-up to #1502 / PR #1591, which made the two resource copies fail-closed. Two neighbouring steps in
scripts/build-release.shkeep the old shape: they log and continue after producing nothing, so the build exits 0 and the gap is only visible downstream.Where
scripts/build-release.sh:566-568— whenresolve_ghostty_share_dirfails, the else-arm logsGhostty share resources not found; packaged shell integration may be degradedand the build goes on. A bundle with no Ghostty resources (no shell integration, noterminfo/78/xterm-ghostty) is produced with exit 0. Todayverify-release-bundle.sh --structure-only(run byci.ymlon the next step, and by the release lane) catches it asMissing Ghostty resources directory, so the consequence is a false-green build step rather than a shipped bundle. Codex rated it Medium on fix(release): resource copies into the bundle fail the build instead of logging success #1591; declined there on the fence.scripts/build-release.sh:576-581—actool … 2>/dev/null || log_warning "Asset compilation had warnings". A failed compile leaves an app withoutAssets.car, logged as a warning.verify-release-bundle.shdoes not assertAssets.car, so nothing downstream catches an iconless bundle.What to decide
--no-signbuild before changing the step.Requested Evidence
scripts/tests/test_build_release_copies.py(or a sibling) asserting the chosen behaviour for each step, red before the change./scripts/build-release.sh --no-signend to end followed by./scripts/verify-release-bundle.sh --structure-only build/WorkSpaces.app, both result lines quoteduv run --script scripts/validate-release-changes.pypasses for the changed filesOrchestrator note (workspaces)