Releases on Arcadible

A release is one attempt to publish a version of your game. This page covers what happens between arc deploy and a published build, where you hear the result, and what to do when a release fails.

From deploy to published

Every release ends published or failed:

1. Deployed. arc deploy uploads a zip of your game, or arc deploy git pushes a release tag that GitHub Actions builds (see Deploying from GitHub).
2. Processed. Arcadible reads the zip, checks that its manifest matches the game and version being released, and stores the build.
3. Published. The build is playable at its version link, such as play.arcadible.com/star-drift:1.2.0/. A release version also updates your store page and becomes what players get. Changes can take up to 10 minutes to reach all of Arcadible.

A direct release is published within a few minutes of its upload. A git release is published after its GitHub Actions run, which can take several minutes, depending on the build. A release that hasn't finished within an hour fails as release_expired.

Where you hear about it

Where	Published	Failed
arc deploy	Published v1.2.0 to production. (or Built and published …), with its links	Release failed., with what happened and the reason, and exits with 1
Email	"Release Published", with the version, the channel, and that version's title and icon	"Release Failed", with what happened, the reason, how to fix it, and Studio
GitHub check (git only)	The Arcadible check on the tagged commit passes	The check fails, with what happened, the reason, and how to fix it
Arcadible Studio	The build, on the game's Builds tab	Above the game's builds, and on the Builds page, until a later release publishes

• arc deploy waits by default. It exits with 1 when a release fails, so a script or CI job fails with it. See Waiting for the release.
• Emails go to your account's address, for every release, whichever way you deployed.
• Studio shows where releases stand above the builds: a line for each release on its way, and Releases to fix: N for the failures since the game's last published release. Show why opens each with what happened, its reason, and a link to its fix. Builds ▸ Failed keeps every failure. A first release that fails before the game exists isn't in Studio's game pages; open it from the email's link.
• The GitHub check passes once Arcadible accepts the build, before the store page is written. If a release fails after that, as internal, game_unavailable, or release_expired, the email says so and the check doesn't change.

When a release fails

A version is taken only when its build is published. Fix the cause and deploy the same version again, unless the reason is version_exists. Each reason, and its fix, is in Release failure reasons.

Rolling back

To roll back, deploy the earlier code with a higher version. Arcadible doesn't currently roll back to an earlier build itself: builds can't be deleted one by one, and each stays playable at its version link until its game is deleted. Release limits, such as 30 builds an hour and 100 games an account, are in Limits.

Next steps

• Deploying from GitHub: release from GitHub Actions, with a check on every release commit.
• arc deploy: both deploy methods, waiting, and --json.
• Errors: every message, and every reason a release fails.