Repository navigation
Fix the signing-identity fallback, and check builds on CI - #6
Conversation
`set -e` aborts the script when `grep` finds no "Developer ID Application" line, so the "Apple Development" fallback the loop was written for is never reached. On a machine that only has a development certificate, build-app.sh exits 1 right after "Build complete" with no message, leaving an unsigned, half-assembled bundle in build/. Let the substitution fail quietly so the loop can try the next kind.
The project had no automated checks, so a release could ship a build that does not compile from a clean checkout. This runs on macos-15: swift build, the test suite with the machine-wide scan enabled (a runner starts empty, so the walk that is slow locally is quick here), scripts/build-app.sh, and a check that the assembled bundle has its binary, its Info.plist, the SwiftPM resource bundle Bundle.module needs and a valid signature. The last step reruns compile-strings.sh and fails on a diff, so a catalog edit committed without regenerating the .strings files is caught here rather than as a half-translated menu at runtime. Note: the bundle step needs the signing-identity fix, otherwise build-app.sh aborts on a runner, which has no certificate at all.
Enabling it was wrong: a GitHub runner ships Xcode with its simulator runtimes and device support, so the walk is no quicker there than on a developer Mac. A trial run passed 23 minutes without finishing. Also gives the job a 20-minute ceiling so a hang costs one job rather than the six hours a runner will otherwise sit there.
The workflow from #6 is right, and the signing fix that came with it stays. But this account's Actions are billing-locked — every run ends with 'the job was not started because your account is locked due to a billing issue' — so merging it only put a red cross on main, which is why CI was removed once already. It comes back verbatim from #6 the day a run can start.
Actions are billing-locked on this account, so the workflow from #6 cannot start and merging it only put a red cross on main. The checks are worth having regardless, so they run here instead: build, tests, shellcheck, the bundle's completeness and signature, that it is universal, and that the compiled strings match the catalogue. The release script now calls it rather than repeating a subset of it.
|
Merged, and the signing fix is the valuable half — thank you for reporting what it actually looks like from a clean clone, because a script that dies silently right after The workflow I had to take back out, and it is not a judgement on it. This account's Actions are billing-locked. Every run ends the same way:
That is why the repo had no CI when you found it. Merging the workflow put a red cross on Your checks were not wasted. They now run locally as Six pull requests, six real problems, one of them a bug the app could not have come back from. That is a better first contribution than this project deserved. |
2 participants
The bug.
build-app.shruns underset -euo pipefail. Whengrepfinds no"Developer ID Application"line, it exits 1, the assignment takes that status, and the script dies — before theApple Developmentfallback the loop was written for. On a machine that has only a development certificate, the script exits 1 right afterBuild completewith no message, leaving an unsigned, half-assembled bundle inbuild/. That is what I hit on the first run from a clean clone.|| trueon the substitution lets the loop try the next kind.The CI. The project had no automated checks, so a release could ship a tree that does not build from a clean checkout. The workflow runs on
macos-15:swift build, the test suite,scripts/build-app.sh, and a check that the assembled bundle has its binary, itsInfo.plist, the SwiftPM resource bundleBundle.moduleneeds, and a valid signature. The last step rerunscompile-strings.shand fails on a diff, so a catalog edit committed without regenerating the.stringsfiles shows up there rather than as a half-translated menu at runtime.A runner has no certificate at all, so the bundle step exercises exactly the path the first commit fixes — without it, CI cannot get past
Assemble the app bundle.The machine-wide scan is left off in CI: a runner ships Xcode with its simulator runtimes, so the walk is no quicker there. I tried it — 23 minutes without finishing. The job has a 20-minute ceiling for the same reason.
Green run on my fork, 56 seconds: https://github.com/peechycreation/macos-sysdata/actions/runs/34053096320