Build1 publisher2 min readPublished
Seven of the eight secrets in a Shorebird release workflow exist only to sign the binary
A dev.to walkthrough wires Shorebird's three official actions into a Flutter repository, where seven of the eight secrets exist only to sign store binaries and the patch workflow itself is never shown.
The Engineer · Build desk
What happened
- A dev.to walkthrough by techwithsam wires Shorebird's code-push tooling into GitHub Actions so a Flutter team can run full store releases and reviewless patches out of the same repository.
- Shorebird publishes three official actions: setup-shorebird@v1 installs the tooling on the runner, shorebird-release@v1 creates a release, and shorebird-patch@v1 creates a patch.
- Authentication is a single API key created in the Shorebird console with a chosen expiration and permission set, pasted into a repository secret that every workflow then reads.
- The Android release job decodes a base64 keystore and writes key.properties from secrets, and the finished workflow hands back signed artifacts for manual upload to the stores.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost Seven of the eight secrets are keystore passwords, an Apple certificate and a provisioning profile, so whoever holds the signing material inherits the rotation work every time one of them changes.
- exposure With workflow_dispatch as the only trigger in the printed file, anyone with write access to the repository can start a release from the Actions tab and choose the platform.
- contradiction The prose promises a tag-driven pipeline and the YAML gives a manual one, so a team that copies the file gets different behaviour from what it thinks it installed.
- constraint Pinning the Flutter version is presented as a rule with no stated failure mode, which leaves adopters unable to judge what breaks when release and patch builds drift apart.
The release path and the patch path do not need the same credentials. `shorebirdtech/shorebird-release@v1` produces artifacts you upload to Apple and Google yourself, so the job has to rebuild signing material on a clean runner: decode the keystore and write `key.properties` on Android, or import the `.p12` and the provisioning profile into a temporary keychain on iOS [15][14]. `shorebirdtech/shorebird-patch@v1` gets one line in the article, as the action that creates a patch [4]. The published text breaks off partway through the Android release job and never reaches a patch workflow file [17].
Count what a repository shipping both platforms has to store. Android needs `ANDROID_KEY_ALIAS`, `ANDROID_KEY_PASSWORD`, `ANDROID_STORE_PASSWORD` and `ANDROID_KEYSTORE_BASE64` [12]. iOS needs `IOS_CERTIFICATE_BASE64`, `IOS_CERTIFICATE_PASSWORD` and `IOS_PROVISIONING_PROFILE_BASE64` [14]. Add `SHOREBIRD_TOKEN` and that is eight [18]. Seven of them are signing material [19]. The instructions build the keystore secret with `base64 -i ~/path/to/upload.jks | tr -d '\n' | pbcopy`, which puts your upload keystore on the macOS clipboard on the way to GitHub [13]. That is one more place it now lives.
The Shorebird half is one key, created in the console under Account and then API Keys, with a name, an expiration and a permission set you choose at creation, and shown to you once [6]. "That's the only authentication step you need," techwithsam wrote [8]. The same author is direct about the tooling: "I strongly recommend using these instead of calling the CLI manually. They're cleaner and maintained by the Shorebird team" [5].
Read the trigger before you copy the file. The article's step list opens with "Trigger on version tags: v1.0.0, v1.2.3, etc. or manually trigger the workflow" [10]. The YAML printed underneath declares `on: workflow_dispatch` with a required `platform` input defaulting to `both`, and the `release_android` job is gated by an `if` on that input [16]. In that file a release starts when a person opens the Actions tab and picks a platform. Nothing in it watches for a tag.
One instruction in the step list carries no reason: "Pin your Flutter version (very important)" [11]. That is the line I would want explained before letting a release workflow and a patch workflow drift apart, because the two produce artifacts that have to agree.
The timing claim is the author's own. Store review takes days or weeks for a fix or a small update, and the pipeline is offered as a way to reach users in minutes [2][3]. For that number to transfer to your app it has to include the patch job's build time on a hosted runner and however long clients take to pick a patch up, and the article measures neither [17].
What to watch
- A published patch workflow that shows whether a patch job runs on the token alone, with no keystore or certificate secrets.
- Guidance from Shorebird, or from Apple and Google, on what a code-push patch is permitted to change.
- Whether shorebirdtech's actions grow a revert step for a patch that shipped a bad fix.