Store Deployment

## Why a human login cannot drive an unattended release A store upload is an authenticated API call, and the only real question is whose identity it carries. If the release lane authenticates as a person, then everything that protects that person also blocks the pipeline: an interactive two-factor challenge, a session that expires, a rotated password, and eventually the fact that the person leaves the team. `upload_to_app_store` still accepts an Apple ID through `username`, and that is exactly the path that strands a llama-trekking booking app release overnight, waiting for a code nobody is awake to type. The fix on both stores is the same idea and two completely different implementations: issue a credential that belongs to the **automation** rather than to a human. There is **no shared credential model** — the formats, the option names and the issuing systems all differ. ## Apple: the App Store Connect API key `upload_to_app_store` (`deliver`) reads Apple credentials from these options: - `api_key_path` — a path to a JSON file that carries the key's identifiers together with the private key text. This is the usual CI form. - `api_key` — the same material as a hash already prepared inside the lane, so nothing has to be written to disk. - `username` — an Apple ID. The interactive path, kept for humans running the lane locally. - `team_id` and `team_name` — which team the upload belongs to, when the identity can see more than one. The key is a secret with a scope: it is issued with a role, so an upload can fail on permission rather than on authentication, and revoking or rotating it breaks every lane that uses it at once. ## Google: the service-account JSON key `upload_to_play_store` (`supply`) reads Google credentials from these options: - `json_key` — a path to the service-account JSON key file. - `json_key_data` — the contents of that file as a string, ideal when the credential arrives from an environment variable. - `package_name` — the Android application id the service account is acting on. Note the asymmetry that trips people up: the action has **no `username` option**. There is no human-account path on this side at all; a service account is the only identity Google Play's upload lane will use. ## The two credentials side by side | | iOS — `upload_to_app_store` | Android — `upload_to_play_store` | |---|---|---| | Credential kind | App Store Connect API key | Google service-account JSON key | | File option | `api_key_path` | `json_key` | | In-memory option | `api_key` | `json_key_data` | | Human fallback | `username` (an Apple ID) | none | | Scoping option | `team_id`, `team_name` | `package_name` | The same split shows up wherever fastlane talks to a store: Apple's tools take `api_key`/`api_key_path`, Google's take `json_key`/`json_key_data`. Neither key is convertible into the other, and a lane that ships both platforms needs both secrets. ## Handling the keys in CI 1. Keep both keys out of the repository. A committed service-account key or Apple private key is a store-publishing credential sitting in everyone's clone. 2. Prefer the in-memory option where one exists: `json_key_data` from an environment variable means the Play key never touches the job's disk. 3. When a file is unavoidable — Apple's `api_key_path` — write it from the secret at the start of the job and delete it at the end, inside the job's own workspace. 4. Rotate deliberately. Because one key serves every lane, plan the swap rather than discovering it when a release night fails. 5. Give the credential the narrowest role that still lets the upload succeed. ## Failure modes worth recognising - The lane hangs instead of failing: almost always an Apple ID `username` path asking for a two-factor code. - Authentication succeeds but the upload is refused: the identity is real but has not been granted access to that app, or its role is too narrow. - A key pasted into a single-line environment variable loses the line breaks of its private key text and no longer parses. - Someone points the Apple key at `json_key`, or the Google key at `api_key_path`, and gets an unhelpful parse error rather than a clear message. ## What a machine credential does not buy you It removes the human from the **login**, not from the release. Store review still happens on the stores' terms, and the declarations a submission requires still have to come from somewhere — either from options set on the action or from a person. Machine credentials make an unattended release possible; they do not make it automatic.