Skip to content

Check the disk image, which is what is left after bundling and what ships - #33

Merged
hiroaki222 merged 2 commits into
mainfrom
fix/seal-check-the-dmg
Aug 14, 2026
Merged

hiroaki222 merged 2 commits into
mainfrom
fix/seal-check-the-dmg

Conversation

@hiroaki222

Copy link
Copy Markdown
Owner

The seal check added in #31 failed the v0.3.0 release on a bundle that was
correct. This is that check, looking where the file actually is.

What happened

It searched the build directory for Transcrate.app. Tauri packs the app into
the disk image and then deletes it:

Bundling Transcrate_0.3.0_aarch64.dmg (…/bundle/dmg/Transcrate_0.3.0_aarch64.dmg)
 Running bundle_dmg.sh
Cleaning …/bundle/macos/Transcrate.app
Finished 1 bundle at:
    …/bundle/dmg/Transcrate_0.3.0_aarch64.dmg

Three lines later the step exits with no Transcrate.app was built. Everything
before it — the build, the sidecars, the signing of each nested binary and then
of the bundle — had succeeded.

Why the tests missed it

There were eight of them, against a bundle built for the purpose, and every one
put the .app in place by hand before running the step. The single thing they
could not model was the step that takes it away.

The disk image the failed run produced was still attached to the draft release.
Pulled down and opened, it holds Transcrate.app with ffmpeg and ffprobe in
Contents/MacOS, and codesign --verify --deep --strict reports it valid. The
bundle was never the problem.

The change

Mount the .dmg, find the app inside it, and ask the same two questions of
that: are the sidecars beside the executable, and does the seal hold.

This is not a way around the deletion. The disk image is the file people
download, and until now nothing in this pipeline had looked inside one.

Tried

Against the image from the failed run, and against images rebuilt from it with
one thing wrong each.

result
the image the failed run produced passes
sidecar moved to Contents/Resources not beside the executable, and says where it is
sidecar replaced after signing nested code is modified or invalid
sidecar removed not beside the executable
image with no application in it the disk image holds no application
no image built at all no disk image was built

Run under /bin/bash 3.2, as the runner has.

After merging

The v0.3.0 tag and its draft are still where the failed run left them. The
draft was never published, so both come down and the tag goes back on main,
for one clean run rather than a re-run against the old workflow.

The check looked for Transcrate.app in the build directory. Tauri packs it
into the .dmg and then deletes it — 'Cleaning .../Transcrate.app' is in the
log, three lines above the step failing with 'no Transcrate.app was built'.
It failed the release for v0.3.0 on a bundle that was correct.

The local tests never caught it because they put the .app there by hand. The
one thing they could not model was the step that removes it.

Reading the .dmg instead is not a workaround. It is the file people download,
and until now nothing had looked inside one.

Tried against the disk image the failed run produced, pulled from the draft
release: it passes. And against images built from it with a sidecar moved to
Contents/Resources, a sidecar replaced after signing, a sidecar removed, and
no application at all, each of which it refuses.
@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@hiroaki222, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 70 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 4120f983-662b-4a1b-aa88-406466eaa646

📥 Commits

Reviewing files that changed from the base of the PR and between 7d15803 and 9f14a7b.

📒 Files selected for processing (1)
  • .github/workflows/release.yml

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@hiroaki222
hiroaki222 merged commit 9ee6d7e into main Aug 14, 2026
6 checks passed
@hiroaki222
hiroaki222 deleted the fix/seal-check-the-dmg branch August 14, 2026 00:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant