Forge builds and artifacts

A build is one commit of one project, exported once per target. Each target runs on its own, in its own container, and produces exactly one file.

Targets

Every target is exported on Linux, macOS and iOS included: an export fuses your scripts, scenes and assets onto a prebuilt engine for that platform, so no compiler for it has to run.

Build settings

On Projects, Settings beside a project holds what its builds do. The same fields are on the API as PATCH /api/v1/forge/projects/:id.

• Name and default branch. The branch a manual build uses.
• Targets. The platforms every build exports.
• Engine version. latest follows the newest runtime templates. Pin a version such as 0.4.1 and the same commit builds the same bits next month, which is what a release branch wants. nightly follows the engine's nightly build.
• Android packages. APK installs on a device and is what itch.io and sideloading take. App Bundle is what Google Play takes for a new app. Choose both and one build makes both: two artifacts, each signed with your Android key, each with its own Publish button. The bundle shows on the build as android (aab).

What the game itself decides stays in the game: stripping unused assets, re-encoding images, subsetting fonts and build tags are [export] in its project.toml, committed with the code, and Forge uses them as they are.

What a build can reach

• Your repository, one commit deep, read-only. Forge clones the pushed commit — or the head of the branch you asked for — and nothing else.
• No network. A build cannot download a package, fetch an asset or call an API. Everything the export needs has to be in the repository.
• Submodules and Git LFS, fetched before the build. Submodules are checked out one commit deep, recursively, and LFS files are pulled, in submodules too — so assets kept in LFS arrive as assets. Submodules have to be reachable over https: from GitHub through the same App access as the project, or public. A submodule pointing at a local path or file:// is refused.

Reading a build's page

Each target's card shows its status, and once it succeeds:

• cached — the engine template for this target and version was already on the builder, which is most of why a warm build takes seconds.
• signed or unsigned — and when unsigned, what signing would need, with a link to set it up.
• the file's size, and Download.
• a Publish to … button for each store you have set up that takes this target. See Stores.

Under the cards is the build's Output: the clone, then the export, line by line as it happens. A failed target's reason is on its card; the lines above it in the output say why. Troubleshooting has the common ones.

A build is queued until a builder picks it up, running while any target is, and succeeded or failed once all of them have finished — failed if any one did.

Limits on balaurengine.org

A target that fails is not retried: a red export is almost always the project, and running it again would fail the same way on your time.

Deleting your account deletes everything Forge keeps for it: every build's downloads, every hosted game, and every signing credential and store key. The account goes at once; the files follow within minutes.

The same commit, the same file

Exports are reproducible: the same commit, target and engine version produce the same bytes, whichever builder ran them. The digest on a GitHub check is therefore something you can check a download against.