This document describes the automated release pipeline that manages version bumping, package publishing, Docker image builds, and GitHub release creation for Trigger.dev. The system uses changesets for npm package versioning and a custom .server-changes/ convention for server-only changes.
For information about the Docker build process itself, see Docker Build Pipeline. For deployment workflows, see Deployment Process. For CI/CD testing workflows, see CI/CD Integration.
The release automation system is composed of three GitHub Actions workflows and two Node.js scripts that coordinate version management, publishing, and release note generation.
Release Automation Workflow
Sources: .github/workflows/changesets-pr.yml .github/workflows/release.yml .github/workflows/publish.yml scripts/enhance-release-pr.mjs scripts/generate-github-release.mjs
Developers contribute changes using changesets for package modifications and .server-changes/ files for server-only changes.
Changeset vs Server Changes Decision Tree
Sources: CONTRIBUTING.md249-302 CHANGESETS.md1-38 .server-changes/README.md
For changes to published packages (anything in packages/), developers run:
This invokes the @changesets/cli tool, which prompts for:
@trigger.dev/sdk, trigger.dev)patch (bug fixes), minor (new features), or major (breaking changes)The tool creates a markdown file in .changeset/ with a randomly generated name (e.g., .changeset/happy-owls-dance.md):
Sources: CONTRIBUTING.md249-269 CHANGESETS.md5-7
For server-only changes (code in apps/webapp/, apps/supervisor/, apps/coordinator/, etc.), developers create a .server-changes/ file:
The frontmatter requires two fields:
area: One of webapp, supervisor, coordinator, kubernetes-provider, or docker-providertype: One of feature, fix, improvement, or breakingSources: CONTRIBUTING.md270-302 .server-changes/README.md13-40
The changeset system is configured in .changeset/config.json:
| Configuration | Value | Purpose |
|---|---|---|
changelog | @remix-run/changelog-github | Automatically fetches PR links for changelog entries |
fixed | [["@trigger.dev/*", "trigger.dev"]] | All public packages share the same version |
baseBranch | main | Release PRs target the main branch |
ignore | webapp, coordinator, etc. | Server apps excluded from changesets (not published to npm) |
updateInternalDependencies | patch | Internal dependency updates trigger patch bumps |
The fixed constraint ensures that all packages released under the @trigger.dev/ scope and trigger.dev CLI maintain version parity (e.g., all release as 4.3.2 together).
Sources: .changeset/config.json
The changesets-pr.yml workflow runs on every push to main that modifies packages or changesets.
Changesets PR Creation Flow
Sources: .github/workflows/changesets-pr.yml scripts/enhance-release-pr.mjs
The enhance-release-pr.mjs script transforms the raw changeset output into a structured release summary:
Script Processing Pipeline
Key Functions:
parsePrBody(body) scripts/enhance-release-pr.mjs34-85: Extracts bullet points from changeset output, deduplicates by PR number, filters out dependency-only updates, and categorizes entries by type based on text analysisparseServerChanges() scripts/enhance-release-pr.mjs142-190: Reads .server-changes/*.md files, parses frontmatter, looks up git commits via getCommitForFile(), fetches associated PR numbers from GitHub API via getPrForCommit(), and appends PR links to descriptionsformatPrBody() scripts/enhance-release-pr.mjs209-305: Generates structured sections with counts, organizes entries by category, includes server changes separately, and collapses raw changeset outputSources: scripts/enhance-release-pr.mjs
After the PR body is enhanced, the update-lockfile job in changesets-pr.yml performs cleanup:
changeset-release/main branchpnpm install --no-frozen-lockfile to update pnpm-lock.yaml with new versions.server-changes/*.md files (except README.md) using git rmThis ensures that merged .server-changes/ files don't accumulate on main after the release PR merges.
Sources: .github/workflows/changesets-pr.yml76-124
The release.yml workflow triggers when the release PR merges to main or via manual workflow dispatch.
Release Workflow Trigger Conditions
Sources: .github/workflows/release.yml1-47
The release job orchestrates npm publishing and GitHub release creation:
Release Job Execution Flow
Sources: .github/workflows/release.yml48-155
The workflow uses OpenID Connect (OIDC) for secure npm publishing without long-lived tokens:
npm-publish environment with permissions for contents: write, packages: write, and id-token: writenpm@11.6.4 because OIDC support requires npm v11.5.1 or newerpnpm run changeset:release which calls changeset publish, authenticating to npm via OIDC without explicit NPM_TOKENThe OIDC flow automatically exchanges a GitHub Actions JWT for npm publish credentials during the workflow run.
Sources: .github/workflows/release.yml92-116
After npm publishing succeeds, the workflow creates a unified GitHub release:
GitHub Release Creation Process
Key Script Functions:
extractChangesFromPrBody(body) scripts/generate-github-release.mjs41-85: Extracts content between first ## heading and <details> block, skips "Summary" section, preserves Highlights/Improvements/Bug fixes/Server changes sectionsgetContributors(previousVersion) scripts/generate-github-release.mjs89-120: Runs git log vPREV...HEAD --format="%aN|%aE" --no-merges, extracts GitHub usernames from noreply emails, sorts by commit countgetPublishedPackages() scripts/generate-github-release.mjs123-151: Reads packages/*/package.json, filters out private packages, returns sorted listformatRelease() scripts/generate-github-release.mjs171-236: Builds final release body with upgrade commands, Docker image link (initially generic), release notes link, changes content, package list, contributor mentions, and changelog comparison linkSources: .github/workflows/release.yml125-136 scripts/generate-github-release.mjs
After the GitHub release is created, the workflow triggers Docker image builds.
Docker Image Publishing Flow
Sources: .github/workflows/release.yml138-196 .github/workflows/publish.yml
The workflow uses a v.docker. tag prefix to trigger Docker builds:
v.docker.4.3.2 tag pointing to the release commitpublish.yml workflow has a push.tags trigger for v.docker.* patternGITHUB_TOKEN), the release workflow explicitly calls publish.yml via workflow_call with image_tag: vVERSIONThis dual approach ensures Docker builds trigger reliably even with GitHub Actions limitations.
Sources: .github/workflows/release.yml138-154 .github/workflows/publish.yml1-79
After Docker images are pushed to GitHub Container Registry, the update-release job patches the GitHub release with the exact GHCR package URL:
gh api to fetch all versions of trigger.dev container, filters by tag using jqhttps://github.com/triggerdotdev/trigger.dev/pkgs/container/trigger.dev/{VERSION_ID}?tag=vVERSIONsed to replace the generic container page link with the tag-specific URLThis ensures users can click the Docker image link in the release and land directly on the correct tagged image.
Sources: .github/workflows/release.yml158-196
After the release is complete, the workflow dispatches a repository event to the marketing site repo:
The marketing site repo listens for new-release events and automatically creates a PR to add a changelog entry for the new version.
Sources: .github/workflows/release.yml199-211
The release.yml workflow also supports prerelease builds via manual workflow dispatch:
Prerelease Configuration
| Input | Description | Default |
|---|---|---|
type | Release type (release or prerelease) | prerelease |
ref | Branch, tag, or SHA to release from | Required |
prerelease_tag | npm dist-tag for the prerelease | prerelease |
Prerelease Job Flow
The --snapshot flag generates temporary versions (e.g., 4.3.2-prerelease-20250123120000) without creating git tags or modifying package.json files on the branch.
Sources: .github/workflows/release.yml213-265
Both workflows use concurrency controls to prevent conflicts:
Changesets PR Workflow:
Allows canceling stale runs when new commits push to main.
Release Workflow:
Ensures only one release runs at a time, never cancels in-progress releases.
Sources: .github/workflows/changesets-pr.yml14-16 .github/workflows/release.yml28-30
The release workflow defines explicit job dependencies to ensure correct execution order:
All dependent jobs check needs.release.outputs.published == 'true' to ensure they only run when packages were actually published.
Sources: .github/workflows/release.yml48-211
| Workflow | Trigger | Purpose | Key Outputs |
|---|---|---|---|
changesets-pr.yml | Push to main with changesets/server changes | Create/update release PR | Enhanced PR body, version-bumped package.json, cleaned .server-changes/ |
release.yml (release job) | Release PR merge or manual dispatch | Publish packages to npm | Published npm packages, GitHub release, v.docker.VERSION tag |
release.yml (prerelease job) | Manual dispatch with type: prerelease | Publish snapshot versions | Prerelease packages on custom dist-tag |
publish.yml | Called by release.yml or tag push | Build Docker images | Docker images on GHCR |
release.yml (update-release job) | After Docker publish | Update GitHub release | Release with exact GHCR link |
release.yml (dispatch-changelog job) | After release complete | Trigger marketing site PR | Repository dispatch event |
Sources: .github/workflows/changesets-pr.yml .github/workflows/release.yml .github/workflows/publish.yml
Refresh this wiki