-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate MacOS Code-Signing in CICD #253
Comments
This issue is in TypeScript-Demo-Lib because it affects anything that is macos application. |
I think we should be using fastlane. But we will see more about this when we create a mobile application react-native. |
At this point in time we are using the If we want to package it as a Now if you want to go into the Mac app store, then we have another 2 kinds of certificates. In the new xcode 11 we can create one that works for all:
The ad-hoc distribution is used for test device deployment (outside of the mac app store). Basically distributing to beta testers. For mobile development, the ios apps are
Test flight is the system provided by Apple, it allows other users of iphone to download the app easily and test it. It's better than distributing to devices designated in the developer account. So it appears the purpose of adhoc provisioning is to send to beta testers which are all orchestrated and registered under testflight. I will need third party expertise to setup the testflight account details. Testers use the testflight app to install these beta-builds and can provide feedback. It appears fastlane is just a "CLI tool" that therefore can also "upload" to testflight. To setup testflight, you also need an "App Store Connect" account. This is part of the Apple developer account. Anyway:
|
So we can use fastlane in our Gitlab CI/CD, provide the necessary secrets in our CI/CD which will then do code signing, notarisation, and stapling (requiring For the GUI application which would make sense to distribute on the app store, one would then instead use the This makes me wonder. What the is purpose of So for a GUI app destined for the app store, one may use:
The usage of Is it possible to codesign the same app with all 3 certificates? More details here: https://docs.fastlane.tools/best-practices/continuous-integration/ |
I think the consensus is that you're supposed to use Once you finish development, you make a choice:
Perhaps both could be done, so you could also download the app from outside the app store and run it too. This seems to only apply to MacOS though, there's no official way of doing side-loading on ios. |
I believe the This means you can use the development certificate to run on our local device, or local devices (possibly within the development team). And then use distribution certificate for ad-hoc distribution to a closer group of beta testers, testflight for more larger scale beta testers and finally app store. The last 3 stages are all using the In xcode, they don't just refer to certificates, they refer to "profiles", which probably select the certificates along with some other settings. https://help.apple.com/xcode/mac/current/#/dev31de635e5 |
Android builds don't require code signing, the apk can be downloaded from the internet and executed. However once they go into the google play store, they will require code signing and packaging into an I think the beta equivalent for Testflight on Google Play is just Google Play beta, it's not really a service, you're just pushing up builds with the ability for users to opt in and download beta versions of the application. |
More details here:
Seems like it has good information for automating this on Linux instead of automating all the MacOS steps. |
This will now be in Polykey-CLI, and done there instead. |
The TypeScript-Demo-Lib isn't really relevant anymore. We don't really use it as a guide for any repos. |
Specification
During the integration stage, the final macos executables must be code-signed and notarised in order for them to be a drop-in runnable on end-user systems. This is the case even for applications distributed outside of the app store.
I have succesfully done this manually inside the
matrix-mac-1
. However this should be done by our CICD duringintegration:macos
job before we do a prerelease or release.The exact process of doing this may change if we were to integrate Nix: MatrixAI/TypeScript-Demo-Lib-Native#1. In this case, it would be better to have the Nix produce the final output, and have the code signing and notarisation part of the Nix process. However notarisation involves contacting the Apple mothership, and this may mean we require an "impure" build shell which basically means disabling the sandbox.
Additional context
login
keychain passwordDeveloper ID Application
key and certificate into our CICD system, this must be a protected variablezip
format, but if thepkg
format allows to staple the notarization onto the executable, then it should be investigated further, because we could also release thepkg
format, while having the bare executable aroundTasks
The text was updated successfully, but these errors were encountered: