Skip to main content
Tabby AI Keyboard uses GitHub Actions to automatically build and release Windows installers. This guide explains how the release workflow functions and how to trigger new releases.

​
Release Workflow Overview

The release workflow is defined in .github/workflows/release.yml:1-46 and automatically:
  1. Builds the Windows application on a Windows runner
  2. Creates a production .exe installer
  3. Publishes a draft GitHub Release
  4. Attaches the installer to the release

​
Prerequisites

1

Configure GitHub Secrets

Add these secrets to your GitHub repository settings (Settings → Secrets and variables → Actions):
Ensure your GH_TOKEN has the repo scope enabled. This is required for creating releases and uploading assets.
2

Verify package.json version

Update the version in frontend/package.json:
The version number will be used for the Git tag and release name.

​
Triggering a Release

1

Navigate to frontend directory

2

Run the release command

Or with npm:
This script (package.json:30):
  • Reads the version from package.json
  • Creates a Git tag (e.g., v0.1.1)
  • Pushes the tag to GitHub
  • Triggers the GitHub Actions workflow

​
Method 2: Manual Git commands

Alternatively, you can create and push tags manually:

​
Method 3: Manual workflow dispatch

You can also trigger the workflow manually from GitHub:
  1. Go to Actions tab in your repository
  2. Select Release workflow
  3. Click Run workflow
  4. Select the branch and click Run workflow
Manual dispatch is useful for re-running failed builds or testing the workflow.

​
Release Workflow Details

The workflow runs on windows-latest and executes the following steps:
1

Checkout code

Clones the repository at the tagged commit:
2

Setup build environment

Installs pnpm 9 and Node.js 20 with dependency caching:
3

Install dependencies

4

Build and publish

Builds the application and creates the GitHub Release:
The electron-builder configuration (package.json:141-147) automatically publishes to GitHub:

​
Release Artifacts

After the workflow completes successfully:
  1. A draft release is created at https://github.com/YOUR-USERNAME/YOUR-REPO/releases
  2. The Windows installer (.exe) is automatically attached
  3. The release name follows the format: v${version} (e.g., v0.1.1)
Releases are created as drafts by default. You’ll need to manually publish them from the GitHub Releases page after reviewing.

​
Workflow Triggers

The release workflow triggers on:
  • Tag push: Any tag starting with v (e.g., v0.1.0, v1.2.3-beta)
  • Manual dispatch: Can be triggered manually from GitHub Actions UI

​
Best Practices

​
Versioning Strategy

Follow semantic versioning:
  • Major (v1.0.0): Breaking changes
  • Minor (v0.1.0): New features, backwards compatible
  • Patch (v0.0.1): Bug fixes

​
Pre-release Tags

For beta or alpha releases:

​
Testing Before Release

  1. Test the local build first:
  2. Verify the installer works on a clean Windows system
  3. Only then trigger the GitHub release
Once a release is published, avoid deleting tags or releases. If you need to fix issues, increment the version and create a new release.

​
Troubleshooting

​
Workflow Fails at Build Step

  • Check that all GitHub Secrets are configured correctly
  • Review the workflow logs for specific error messages
  • Ensure the version in package.json is valid

​
Release Not Created

  • Verify GH_TOKEN has repo scope
  • Check that the tag format matches v* pattern
  • Ensure electron-builder publish configuration is correct

​
Multiple Releases for Same Tag

If you push the same tag multiple times:
  1. Delete the existing release from GitHub
  2. Delete the tag: git tag -d v0.1.0 && git push origin :refs/tags/v0.1.0
  3. Create a new tag with incremented version