Hacker News new | ask | show | jobs
by ttoinou 1879 days ago
For our small software company, notarization took at least 40 hours of additional work, and slows down releases.

Anyone knows if "stapling" the distributed bundles files (.app .pkg executable files etc.) is useful in any way ?

2 comments

I rearranged my CI graph to run notarization in parallel with my unit tests, and turned on GitLab's DAG to allow jobs from different stages to run at the same time as long as their dependencies are satisfied, so the impact of the notarization step has been small.

My CI pipeline is build -> test -> deploy. The Mac "build" job uploads the app for notarization as a side effect. There is an additional "mac archive" job during the test stage. This job runs general tests on the DMG (checks code signing is valid, makes sure I'm not depending on system libraries), then waits for notarization to finish and staples the DMG. By the time I'm done mounting and checking the DMG, notarization is almost done anyway.

My typical release time right now (from git push to having a fresh app available to install for windows/linux/mac) is 7 minutes. I think I could get it down to around 3 minutes with optimizations.

My primary bottleneck right now is building / xz-compressing a windows installer (which means my windows tests finish last).

Oh, I do notarization after building my .zip containing my .pkg, are you saying I could notarize each bundle separately and I dont need to notarize the final .zip ?
My final artifact is a dmg. I emit it as part of the app build, in my very first CI stage on Mac, and immediately upload for notarization before the build job ends. Then, in parallel to tests, I have a separate job that checks the dmg for common issues, then waits for notarization and staples it.
The stapled information is used the first time someone tries to open the distributed bundle on computers that are not connected to the Internet.