itch is continuously being built, tested, and deployed, to help us keep it high-quality and low on bugs.
To do so, we run our own instance of GitLab CI:
Since the main repository for itch is on GitHub, and since GitLab CI will only build projects that are hosted on a GitLab instance, itch and associated projects have pages on our GitLab instance:
Developers don't have to worry about the GitLab project page: they should clone
the repository from the Github remote and push to it, as usual. The GitHub project
has a webhook that POSTs a signed payload to a custom service,
fetches from Github and pushes to GitLab on-demand:
itch's CI config is relatively straight-forward, most of the complexity lives
in individual shell scripts in the
The book you're reading right now is compiled from Markdown to HTML using gitbook on every commit.
It is then uploaded to
REF is either
a branch, like
master, or a tag, like
As a result, the bleeding-edge version of this book is always available at:
Unit tests & linting
The codebase is covered by a certain amount of unit tests, in
On every commit, the CI executes all unit tests, and runs the TypeScript compiler in check mode to make sure that there are no compile errors.
The building scripts run some common steps on every platform:
- Compiling TypeScript code down to ES6 (see Coding Style for more details)
- Compiling SASS code down to CSS
- Copying some asset files (vendor CSS/JS/images)
macOS / OS X
.zip is built with
7za (7-zip command-line), .dmg is built with node-appdmg,
with a custom background made in GIMP.
The .desktop file is generated via
release/X.desktop.in files +
locale files are parsed for translations of the app's name and description.
Uploading to GitHub releases
All artifacts are uploaded to the relevant GitHub release pages:
...using gothub, a golang uploader.
Our fork adds the
-R command-line option, which replaces an asset if it
already exists, and is necessary to retry failed uploads to GitHub (which
used to happen a lot).
Actually publishing the release
The automated pipeline only creates a release draft on GitHub - it still needs to be approved by a human before the update server starts serving it to users.
Amos is in charge of that. It is used to be a lot more work before the canary channel was a thing (see below) — previously, one had to download the draft builds, install them on each platform and test them.
Similarly, Bintray packages are created in draft mode and have to be published by hand. The actual "ship it" process looks like:
- Receive phone notification that release is ready (via Pushover)
- Make sure everything looks good
- Edit GitHub draft release, publish it
- Check out both rpm and deb repos on Bintray, publish unpublished packages.
The canary channel
When making large structural changes, it is sometimes useful to have a completely separate version of the app with no expectations of stability.
kitch is exactly that. It is meant to be installed in parallel of the
stable app, and has a distinct branding (blue instead of itch.io pink),
uses different folders (
It can be downloaded either:
- From the update server: https://nuts-canary.itch.ovh/download
- Directly from the releases page: https://github.com/itchio/kitch/releases
Note that releases appear out-of-order on the releases page, because GitHub
associates them all with the same commit, since
kitch is actually an
- Do expect the canary version to break on occasion
- Do report back if you try it and you've found an issue that doesn't seem to be on the issue tracker