The first notarized submission came back Invalid: xcodebuild build injects
com.apple.security.get-task-allow into the signature, which archive would
have stripped and which notarization and App Store review both reject.
build_signed.sh now passes CODE_SIGN_INJECT_BASE_ENTITLEMENTS=NO and
refuses an app still signed with it, before any upload.
notarytool exits 0 on Invalid, and the step learned the result only when
stapling failed with an unrelated-looking CloudKit error. It now reads the
status, and on anything but Accepted prints Apple's log and names the
submission.
The macOS lane has never gone green. It built with the project's Release
signing, which was still Cake's (automatic Apple Development, team
32J6BB6VUS), and failed at "No profiles for 'com.suchsoftware...'". Past
that it would have re-signed the finished app by hand, shipping
keychain-access-groups as a literal "$(AppIdentifierPrefix)" with no
profile to authorise it, and read notary secrets that do not exist.
Now, on the shape Vegan IQ proved for its store build:
- Runner's Release config signs manually under D8PL9F7X33 and takes its
profile name from HASH_BAGS_MACOS_PROFILE, so only the app carries one.
- scripts/macos/build_signed.sh decodes a profile, picks the keychain
identity it was issued for (check_macos_profile.py, from vegan-IQ),
and signs inside xcodebuild; it refuses an app whose entitlements keep
an unexpanded variable or that embeds no profile.
- developer-id lane: hardened runtime, notarize, staple, spctl assess,
zip to the release. app-store lane: productbuild with the installer
identity, pkgutil check, altool upload to App Store Connect.
- The first step refuses a selected lane missing any of its secrets and
names each one. The API key lives under the job's temp dir, not the
runner home.
Not run: no Developer ID or Mac App Store signing material is in the
repository's secrets yet, so the guard is the only part exercised.
jwinterm