CI: overhaul packaging workflow and mobile release options

[tyreseluo]

PR Content

Use makepad-packaging-action to streamline the current makepad release CI workflow for easier centralized management.

• add per-platform inputs and build matrices
• create release once and upload assets via releaseId
• add Android/iOS packaging with TestFlight envs

[kevinaboos]

Thanks Tyrese, I appreciate the overhaul of our packaging logic here.

I have one general concern: the code in release.yml is now a lot harder to read (and most importantly, harder for myself and others to maintain) due to lots of custom actions and python scripts interspersed throughout it. When I glance at the code, I cannot clearly understand what it's doing any more.

The older code was quite a bit easier to understand. Similarly, moly-ai's release.yml file is also easy to read — is there any reason why we wouldn't just copy that?

I'm a bit wary of bringing in a dependency on your new makepad-packaging-action since we (the project-robius org) do not have control over that nor the ability to modify it. If you insist on using that, I'd have to do a full audit of that as well. If you'd like to transfer it to the main project-robius org, that would make it easier for us to rely on it (of course you can maintain full ownership rights of it).

[tyreseluo]

My ideal is to extract certain frequently rewritten packaging functions and processes for consolidated maintenance. Under normal circumstances, this should streamline the packaging workflow.

This including GitHub Releases, iOS and macOS signing, and publish uploads to TestFlight.

I shall proceed to modify another version accordingly.

I'm a bit wary of bringing in a dependency on your new makepad-packaging-action since we (the project-robius org) do not have control over that nor the ability to modify it. If you insist on using that, I'd have to do a full audit of that as well. If you'd like to transfer it to the main project-robius org, that would make it easier for us to rely on it (of course you can maintain full ownership rights of it).

yep, i can transfer it to the main project-robius org.

[tyreseluo]

I have in fact consulted moly-ai's release documentation, which currently supports only a limited number of platforms: Ubuntu 22.04, macOS 14, macOS 13, and Windows 2022. Given that Robrix requires support for multiple CPU architectures, the determine_matrices job employs Python to process the differing output results.

In fact the dora-studio https://github.com/dora-rs/dora-studio/blob/main/.github/workflows/package.yml is so simply when use the action.

In any case, the current Release CI for Robrix is indeed somewhat complex and redundant. I shall look into where further improvements and optimisations can be made.

[kevinaboos]

In fact the dora-studio https://github.com/dora-rs/dora-studio/blob/main/.github/workflows/package.yml is so simply when use the action.

That looks really good. Let's keep using the new packaging action, and copy the structure/style of Dora's action. I'd like to avoid all the complexity this PR introduces, especially the inline python scripts.

[kevinaboos]

@tyreseluo btw I noticed that the original CI builds were quite slow and large, especially Android builds because it was building using the default "dev" cargo profile, which generates full debug info and symbols.

In PR #729, I introduced a new build profile called fast which is now used in CI, and it substantially reduced build times. Just letting you know such that you can preserve that behavior if you make further changes to our CI actions. That being said, it shouldn't really be relevant to this PR specifically, since this one is only concerned with release builds.

[tyreseluo]

1. move makepad-packaging-action to our org see: https://github.com/project-robius/makepad-packaging-action.
2. update and fix makepad-packagin-action some features and bugs.
3. Referencing PR Add a fast cargo profile to accelerate CI builds #729, I've added three new parameters to the makepad-packaging-action:

• MAKEPAD_MOBILE_CARGO_EXTRA_ARGS,
• MAKEPAD_IOS_CARGO_EXTRA_ARGS
• MAKEPAD_ANDROID_CARGO_EXTRA_ARGS.
  These are intended to optimize the relevant aspects currently unfinished in cargo-makepad.

[tyreseluo]

The current Robrix release CI file uses version v1. This version will continue to track the latest 1.x.x releases, with the current version being v1.5.3.

[kevinaboos]

Excellent work, the release script is really easy to read now! Much appreciated.

What should I do to test this out? We can spin up a new alpha release as a test run.

[kevinaboos]

@tyreseluo Oh, I assume we also need to set up various github secrets to let your new makepad-packaging-action succeed for macOS/iOS (the codesigning & notarization steps). Let me know which tokens/secrets/env vars are needed.

[tyreseluo]

oh, i forgot that, you can see these below:

Required for all release jobs:

• ROBRIX_RELEASE: GitHub token/PAT with contents: write permission. （Already setting)

Desktop release setup:

• Linux/Windows: no Apple secrets are required for artifact generation.
• macOS signing/notarization (if enabled):

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APP_STORE_CONNECT_API_KEY_CONTENT
APP_STORE_CONNECT_KEY_ID
APP_STORE_CONNECT_ISSUER_ID

Important behavior:

• If macOS signing/notarization secrets are not set, the build can still produce artifacts, but notarization is skipped and the app may show Gatekeeper warnings.
• If we do not yet possess a certificate such as moly, we may opt to temporarily use signing_identity = ‘-’ for packaging the dmg, although this will trigger Gatekeeper warnings.

Mobile release setup (iOS):

• APPLE_CERTIFICATE: Base64 string of .p12.
• APPLE_CERTIFICATE_PASSWORD: password for the .p12.
• APPLE_PROVISIONING_PROFILE: Base64 string of .mobileprovision.
• APPLE_KEYCHAIN_PASSWORD: temporary keychain password.

If uploading to TestFlight:

• APP_STORE_CONNECT_API_KEY_CONTENT: raw multi-line .p8 content (not base64 in current workflow).
• APP_STORE_CONNECT_KEY_ID: Apple API Key ID (usually 10 chars).
• APP_STORE_CONNECT_ISSUER_ID: issuer UUID.

Recommended secret preparation:

• Convert .p12 and .mobileprovision to single-line base64 before saving to GitHub Secrets.
• Keep APP_STORE_CONNECT_API_KEY_CONTENT as plain multi-line text exactly as in the .p8 file.

[tyreseluo]

Summary

For the time being, you only need to add these:

• linux/window/android: no need.
• macos: setting signing_identity = ‘-’ for temp, if we are ready to release a stable version, we need certs and profile.
• ios: the aforementioned parameters must be uploaded. Should we possess a certificate, we may naturally configure relevant TestFlight parameters to publish it to TestFlight, much like moly.

But i think we can consider packaging linux/windows/android for test alpha version first to check this action.

[kevinaboos]

Thanks for the details! Supposedly we have access to the GOSIM account, I just need to set it up and grab the certificates. I'll try that out next week when Edward is back in town, as he's the one who manages that.