This document describes the release process for ShipSec Studio, including Docker image releases and npm package versioning.
Docker Image Releases
Automatic Release (Recommended)
When you push a git tag matching the pattern v*.*.* (e.g., v1.0.0, v1.2.3), the GitHub Actions workflow automatically:
- Builds all three Docker images (backend, worker, frontend)
- Tags images with:
- Version tag:
ghcr.io/shipsecai/studio-{service}:{version}
- Latest tag:
ghcr.io/shipsecai/studio-{service}:latest
- Pushes images to GitHub Container Registry (GHCR)
- Creates a GitHub release with changelog
Creating a Release
# 1. Ensure you're on main branch and up to date
git checkout main
git pull origin main
# 2. Create and push a tag
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0
# The workflow will automatically build and release
Manual Release
You can also trigger a release manually via GitHub Actions UI:
- Go to Actions → Release workflow
- Click “Run workflow”
- Enter the version tag (e.g.,
v1.0.0)
Images are tagged as:
| Service | Image |
|---|
| Backend | ghcr.io/shipsecai/studio-backend:{version} |
| Worker | ghcr.io/shipsecai/studio-worker:{version} |
| Frontend | ghcr.io/shipsecai/studio-frontend:{version} |
All images also have a :latest tag.
Pulling Images
# Pull a specific version
docker pull ghcr.io/shipsecai/studio-backend:1.0.0
# Pull latest
docker pull ghcr.io/shipsecai/studio-backend:latest
NPM Package Versioning
Current State
This is a monorepo with workspace packages:
| Package | Version | Published |
|---|
@shipsec/shared | v0.1.0 | No |
@shipsec/component-sdk | v0.1.0 | No (private) |
@shipsec/backend-client | v0.1.0 | No |
@shipsec/studio-backend | v0.1.0 | No |
@shipsec/studio-worker | v0.1.0 | No (private) |
@shipsec/studio-frontend | v1.0.0 | No |
These packages are workspace dependencies and are not published to npm. They’re consumed internally within the monorepo.
Versioning Options
Option 1: Manual Versioning (Current)
When to use: Small teams, infrequent releases, packages not published to npm.
# Update package.json versions manually before release
# Commit version changes
# Tag release
Option 2: Sync with Docker Release Tag (Recommended)
Since packages aren’t published to npm, sync versions with Docker releases:
# Sync all package versions with release tag
bun run scripts/sync-versions.ts v1.0.0
Option 3: Changesets (For Published Packages)
When to use: If you plan to publish packages to npm.
bun add -D @changesets/cli
bun changeset init
bun changeset # Add changeset
bun changeset version # Version packages
bun changeset publish # Publish to npm
Release Checklist
Before creating a release:
Create the release:
Required GitHub Secrets
The release workflow uses GITHUB_TOKEN which is automatically provided by GitHub Actions. No additional secrets are required for GHCR.
Troubleshooting
Images not appearing in GHCR
- Check workflow logs for errors
- Verify
GITHUB_TOKEN has packages:write permission
- Ensure repository has GitHub Packages enabled
Release not created
- Check workflow logs
- Verify tag format matches
v*.*.*
- Check GitHub Actions permissions
Build failures
- Run tests locally:
bun run test
- Run typecheck:
bun run typecheck
- Check for uncommitted changes
- Verify all dependencies are installed
Semantic Versioning
Follow Semantic Versioning:
| Change Type | Version Bump | Example |
|---|
| Breaking changes | Major | 1.0.0 → 2.0.0 |
| New features | Minor | 1.0.0 → 1.1.0 |
| Bug fixes | Patch | 1.0.0 → 1.0.1 |
Commit Message Convention
Use Conventional Commits:
feat: add new workflow component
fix: resolve authentication issue
docs: update installation guide
chore: update dependencies