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):
Secret NameDescription
GH_TOKENGitHub Personal Access Token (classic) with repo scope
NEXT_PUBLIC_SUPABASE_URLYour Supabase project URL
NEXT_PUBLIC_SUPABASE_ANON_KEYYour Supabase anonymous key
NEXT_PUBLIC_APP_NAMEApplication display name
NEXT_PUBLIC_APP_ICONApplication icon path
NEXT_PUBLIC_API_URLBackend API URL
NEXT_PUBLIC_MEMORY_API_URLMemory service API URL
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:
{
  "name": "tabby",
  "version": "0.1.1",
  // ...
}
The version number will be used for the Git tag and release name.

​
Triggering a Release

1

Navigate to frontend directory

cd frontend
2

Run the release command

pnpm run release
Or with npm:
npm run release
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: 
# Create a tag matching the version
git tag v0.1.1

​
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:
- name: Checkout
  uses: actions/checkout@v4
2

Setup build environment

Installs pnpm 9 and Node.js 20 with dependency caching:
- name: Install pnpm
  uses: pnpm/action-setup@v4
  with:
    version: 9

- name: Install Node.js
  uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: "pnpm"
    cache-dependency-path: frontend/pnpm-lock.yaml
3

Install dependencies

- name: Install dependencies
  run: |
    cd frontend
    pnpm install
4

Build and publish

Builds the application and creates the GitHub Release:
- name: Build and Publish
  run: |
    cd frontend
    pnpm run dist
  env:
    GH_TOKEN: ${{ secrets.GH_TOKEN }}
    # ... environment variables
The electron-builder configuration (package.json:141-147) automatically publishes to GitHub:
"publish": [
  {
    "provider": "github",
    "owner": "CubeStar1",
    "repo": "ai-keyboard",
    "releaseType": "draft"
  }
]

​
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: 
on:
  push:
    tags:
      - "v*"
  workflow_dispatch:
  • 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: 
git tag v0.2.0-beta.1
git push origin v0.2.0-beta.1

​
Testing Before Release

  1. Test the local build first: 
    cd frontend
pnpm run dist
  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

Build docs developers (and LLMs) love

Get started for freeTalk to us