fix(ci): unbreak Companion Desktop Builds on all three platforms - #54
Merged
Merged
Conversation
… builds
Companion Desktop Builds failed on ubuntu-latest and windows-latest with
a macOS path, on machines that have no Xcode:
ubuntu: error occurred in cc-rs: failed to find tool
"/Applications/Xcode.app/.../usr/bin/clang" (os error 2)
-> failed to run custom build command for `ring v0.17.14`
windows: error occurred in cc-rs: failed to find tool
"/Applications/Xcode.app/.../usr/bin/clang++" (os error 3)
-> vswhom-sys v0.1.3
desktop/src-tauri/.cargo/config.toml set CC and CXX in a bare [env]
table. Cargo applies [env] to every invocation regardless of --target,
and cc-rs only prefers a target-suffixed override (CC_<triple>) when one
exists, otherwise falling back to bare CC. So both non-Apple legs were
handed an Xcode toolchain path that cannot exist on those runners. Only
the sibling `linker` key was target-scoped, which is why this looked
platform-guarded but was not.
The repo root .cargo/config.toml already carries the correctly scoped
equivalents for this exact purpose:
[target.aarch64-apple-darwin] linker = "/usr/bin/clang"
CC_aarch64_apple_darwin = "/usr/bin/clang"
CXX_aarch64_apple_darwin = "/usr/bin/clang++"
AR_aarch64_apple_darwin = "/usr/bin/ar"
Cargo discovers it by walking up from desktop/src-tauri, so deleting the
override leaves macOS ARM fully configured while Linux and Windows fall
back to their native toolchains (gcc/cc, MSVC). It also drops a
hardcoded /Applications/Xcode.app path in favour of /usr/bin/clang, the
xcrun shim, which resolves through the active developer dir instead of
assuming one install location.
The file entered the tree in 3257e72, a docs commit for the model
registry contributor guide, alongside no other Rust build changes -- a
local machine workaround committed by accident rather than a deliberate
per-crate override.
Verified locally on aarch64-apple-darwin with
`cargo -Z unstable-options config get env`: before removal cargo
resolved both bare CC/CXX and the target-scoped pair; after removal only
the target-scoped pair remains.
…auri.conf.json
The macos-latest leg of Companion Desktop Builds compiled and bundled
cleanly, then died in codesign:
Signing with identity "$APPLE_SIGNING_IDENTITY"
$APPLE_SIGNING_IDENTITY: no identity found
Error failed to bundle project: failed codesign application
tauri.conf.json carried `"signingIdentity": "$APPLE_SIGNING_IDENTITY"`.
Tauri performs no shell expansion on that field, so the literal string
`$APPLE_SIGNING_IDENTITY` was handed to codesign as an identity name.
The value was never load-bearing anywhere. tauri-cli resolves the
identity as (interface/rust.rs):
match env::var_os("APPLE_SIGNING_IDENTITY") {
Some(v) => Some(v), // env wins
None => config.macos.signing_identity // config only as fallback
}
Both signing workflows already export that env var --
macos-release.yml sets it from secrets.APPLE_TEAM_ID and
desktop-macos.yml from secrets.APPLE_SIGNING_IDENTITY -- so the config
literal was always shadowed there and only ever surfaced in workflows
that sign nothing, where it could do nothing except fail.
Removing it lets tauri-bundler take its documented no-credentials path:
sign::keychain() returns None when neither APPLE_CERTIFICATE nor an
identity is present, and bundling proceeds unsigned. Release signing is
untouched, because those workflows never read this field.
Companion Desktop Builds is build verification, not distribution: it
still compiles every target and still fails the job on any compile or
bundle regression, it just no longer demands a certificate it is not
given. Signed and notarized artifacts remain the job of
macos-release.yml, with desktop-macos.yml asserting the result via
`codesign --verify --deep --strict`. Documented that split inline so the
next reader does not re-add the placeholder.
acamarata
changed the title
…n icon
With the cargo toolchain fix in place, the windows-latest leg got past
cc-rs and then failed in the Windows resource compiler:
resource.rc(26) : error RC2175 : resource file
desktop/src-tauri/icons/icon.ico is not in 3.00 format
panicked at tauri-winres-0.3.6/src/lib.rs:543:
Failed("RC.EXE failed to compile specified resource file")
desktop/src-tauri/icons/icon.ico was not an icon. It was a 70-byte 1x1
PNG that had simply been given a .ico extension -- its first bytes are
the PNG signature, not the 00 00 01 00 ICONDIR magic RC.EXE requires.
icon.icns is byte-for-byte the same placeholder (identical md5), as are
the three tray-*.png files, so this was a set of stub assets committed
as if they were real.
Regenerated icon.ico from the actual brand artwork already in the repo,
.github/wiki/brand/icons/icon-1k.png (1024x1024), at the seven sizes
Windows shells ask for: 16, 24, 32, 48, 64, 128 and 256 px.
Entries are written as uncompressed DIB rather than PNG-compressed.
Both are legal in an ICO, but PNG-in-ICO is only understood by newer
resource compilers, and the whole point here is to stop depending on
what a particular RC.EXE happens to accept. The cost is file size
(353 KB vs 99 KB), which is irrelevant for a resource linked once into
the binary.
Only icon.ico is changed, because only icon.ico blocks the build.
icon.icns and the tray icons are still 1x1 placeholders -- they produce
a blank-looking app and tray on macOS, but they do not fail any build,
and swapping them is an asset decision rather than a CI fix.
This was referenced Aug 27, 2026
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.
Companion Desktop Buildsgot past the pnpm fix (#52) and then failed in Build Tauri app on all three legs, for three unrelated reasons. Each masked the next, so they only became visible one at a time.$APPLE_SIGNING_IDENTITYicon.icois a 1x1 PNG, not an icon1 — a macOS Xcode path forced onto Linux and Windows
desktop/src-tauri/.cargo/config.tomlsetCC/CXXin a bare[env]table:Cargo applies
[env]to every invocation regardless of--target, and cc-rs prefers a target-suffixed override (CC_<triple>) only when one exists, otherwise falling back to bareCC. Both non-Apple legs got an Xcode path. The adjacentlinkerkey is target-scoped, which is why the file looked platform-guarded but wasn't.Fix: delete the file. The repo-root
.cargo/config.tomlalready carries correctly scoped equivalents, which cargo finds by walking up fromdesktop/src-tauri:macOS ARM stays configured; Linux and Windows fall back to their native toolchains. It also trades a hardcoded
/Applications/Xcode.apppath for/usr/bin/clang, the xcrun shim, which resolves through the active developer dir.The file entered the tree in
3257e72, a docs commit for the model-registry contributor guide, with no other Rust build changes -- a local machine workaround committed by accident.2 — an unexpandable
$APPLE_SIGNING_IDENTITYliteralmacOS compiled and bundled fine, then:
Tauri does no shell expansion on
bundle.macOS.signingIdentity, so that literal string went tocodesignas an identity name.The value was never load-bearing. tauri-cli resolves it as (
interface/rust.rs):macos-release.ymlsecrets.APPLE_TEAM_IDdesktop-macos.ymlsecrets.APPLE_SIGNING_IDENTITYcompanion-build.ymlIt was always shadowed in the workflows that actually sign, and only surfaced in the one that signs nothing, where it could do nothing but fail.
Fix: remove the field.
tauri-bundler'ssign::keychain()returnsNonewhen neitherAPPLE_CERTIFICATEnor an identity is present, and bundling proceeds unsigned. Release signing is untouched, because those workflows never read this field.3 —
icon.icowas a 1x1 PNGWith 1 fixed, windows got past cc-rs and hit the resource compiler:
icons/icon.icowas a 70-byte 1x1 PNG with a.icoextension -- it starts with the PNG signature, not the00 00 01 00ICONDIR magic.icon.icnsis byte-identical (same md5), as are the threetray-*.pngfiles: a set of stub assets committed as if real.Fix: regenerate
icon.icofrom the brand artwork already in the repo (.github/wiki/brand/icons/icon-1k.png, 1024x1024) at 16/24/32/48/64/128/256 px. Entries are written as uncompressed DIB rather than PNG-compressed -- both are legal, but PNG-in-ICO is only understood by newer resource compilers, and the point is to stop depending on what a given RC.EXE accepts.Only
icon.icois changed here, because onlyicon.icoblocks the build.icon.icnsand the tray icons are still 1x1 placeholders; they make the macOS app and tray look blank but fail nothing, and replacing them is an asset decision, not a CI fix. Flagged separately.On not weakening the build
No
continue-on-error, noif: false, no dropped matrix leg, no loosened assertion. All three platforms still build and still fail the job on any compile or bundle regression.Companion Desktop Buildsis build verification, not distribution, so it now produces an unsigned macOS artifact instead of demanding a certificate it is never given. Signing correctness stays enforced where it belongs:macos-release.ymlsupplies the real certificate secrets anddesktop-macos.ymlasserts the result withcodesign --verify --deep --strict. That split is documented inline so the placeholder does not get re-added.Verification
Resolved cargo config on
aarch64-apple-darwin,cargo -Z unstable-options config get env:cargo checkindesktop/src-taurion macOS aarch64:Finished, exit 0, zero cc-rs errors.icon.icoparsed back: 7 entries, all DIB, 44,778 non-transparent pixels at 256px.tauri-cli/tauri-bundler/tauri-winressource and to the file's actual bytes, not inferred from symptoms.pull_requesttrigger, so it cannot run as a PR check -- dispatching against the branch is the only pre-merge verification available, same approach as fix(ci): give Companion Desktop Builds pnpm before it runs beforeBuildCommand #52.