← Back to Docs

// DOCS / RELEASES

Release Automation

ThreatCrush now has workflow definitions for CLI publishing, desktop releases, Docker publishing, package-manager submissions, and native Expo/EAS mobile builds. The important distinction is whether a workflow file merely exists versus whether the required secrets and release habits are actually in place.

Current workflow map

PR Checks

.github/workflows/pr-checks.yml

Runs on pushes and pull requests to main/master. This is the workflow that is definitely active right now.

Active baseline

Desktop Release

.github/workflows/desktop-release.yml

Builds desktop artifacts for macOS, Windows, and Linux on version tags or manual dispatch. Needs signing/release secrets to be truly production-ready.

Release workflow present

CLI npm Publish

.github/workflows/npm-publish.yml

Publishes the CLI package on version tags or manual dispatch, assuming the npm token is configured.

Release workflow present

Docker Publish

.github/workflows/docker-publish.yml

Builds and pushes Docker images on version tags or manual dispatch, assuming registry credentials are configured.

Release workflow present

Submit to Package Managers

.github/workflows/submit-packages.yml

Submits artifacts/manifests to package managers after release publication or manual dispatch. Requires multiple packaging secrets.

Release workflow present

Mobile Release

.github/workflows/mobile-release.yml

Builds native mobile artifacts with Expo/EAS for preview or production and can optionally auto-submit production builds.

New Expo/EAS workflow

Secrets / infra still needed

  • EXPO_TOKEN for Expo/EAS mobile builds
  • NPM_TOKEN for CLI publishing
  • DOCKER_USERNAME and DOCKER_TOKEN for Docker Hub publishing
  • Apple signing/notarization secrets for desktop macOS releases
  • Windows certificate secrets for signed Windows desktop releases
  • Package-manager submission secrets (AUR/GPG/Chocolatey/etc.) when using submit-packages

Repo TODO docs

Release/setup gaps are also documented directly in the repo under docs/ so they do not live only in chat context.

  • docs/MOBILE_RELEASE_TODO.md
  • docs/DESKTOP_RELEASE_TODO.md
  • docs/RELEASE_STATUS.md

Recommended release path

1. Keep PR Checks green on normal branch work.

2. Cut version tags when you actually want release automation to fire.

3. Use workflow dispatch for dry runs and partial release testing.

4. Treat the site copy as production-ready only after the related workflow is proven in the Actions UI.