For the sake of testing, it is configured to be triggered manually through the workflow_dispatchevent. It will also cancel any previous instances still running.
The most interesting part is in the steps section. After checking out the repo, the crabnebula-dev/cloud-release action is utilized in each step to run through the entire release process once.
Notice how the command input field does not include the cn prefix. The api-key input field of the action should be set using a secret. See Secrets in GitHub Actions for more details on how to set secrets properly.
This workflow is specifically tailored to Tauri applications. It can be easily adapted to work with any Tauri app and only requires the app-slug as an input.
The release version number is automatically extracted from the Tauri configuration files. Instead of just uploading assets (like in the previous workflow), the build job builds the Tauri app automatically for Linux, macOS and Windows and uploads the assets directly afterwards.
TAURI_PRIVATE_KEY and TAURI_KEY_PASSWORD secrets need to be set accordingly. See the Tauri Docs for more details.
The following workflow is specifically tailored to cargo-packager applications.
Only the app-slug needs to be specified as workflow input. Similarly to the Tauri workflow, the release version number is automatically extracted from the Cargo.toml file. The build job builds the packager app automatically for Linux, macOS and Windows and uploads the assets directly afterwards.