fix(ci): fix docker image publishing and worker builds by nicktrn · Pull Request #3013 · triggerdotdev/trigger.dev

nicktrn · 2026-02-06T13:33:49Z

Summary

Fix Docker publish automation: The v.docker.* tags pushed by the release workflow using GITHUB_TOKEN don't trigger the publish workflow (GitHub Actions limitation to prevent infinite loops). Added a workflow_call to publish.yml directly from the release job so Docker images are built automatically after npm publish. Tags are still pushed for reference.
Fix worker Containerfiles: The coordinator, docker-provider, and kubernetes-provider builds have been failing since the superjson vendoring change in @trigger.dev/core (fix(core): vendor superjson to fix ESM/CJS compatibility #2949). The Containerfiles now run bundle-vendor before build:bundle to generate the vendor files that esbuild needs.

Context

Docker images on GHCR have been stuck at v4.3.0 — v4.3.1, v4.3.2, v4.3.3 tags existed on GitHub but never triggered publish runs
The worker builds (publish-worker) have been failing on every push to main since Jan 30

Test plan

Verified kubernetes-provider Containerfile builds locally with the fix
Manually dispatched publish workflow for v4.3.1 — all jobs succeeded

The v.docker.* tags pushed by the release workflow using GITHUB_TOKEN don't trigger the publish workflow (GitHub Actions limitation). Add a workflow_call to publish.yml directly from the release job. Also fix worker Containerfiles (coordinator, docker-provider, kubernetes-provider) that fail to build since the superjson vendoring change in @trigger.dev/core — run bundle-vendor before build:bundle.

changeset-bot · 2026-02-06T13:33:55Z

⚠️ No Changeset found

Latest commit: 6631df3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

coderabbitai · 2026-02-06T13:34:16Z

Walkthrough

The pull request introduces a downstream workflow invocation for Docker image publishing and updates three application Containerfiles. The release workflow adds a new job that conditionally triggers the publish.yml workflow after successful artifact publication, passing the released package version as the image tag parameter. Simultaneously, the Containerfiles for the coordinator, docker-provider, and kubernetes-provider applications are updated to add a prerequisite bundle-vendor step for the @trigger.dev/core scope before executing their respective bundle commands.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main changes: fixing Docker image publishing (workflow invocation) and fixing worker builds (Containerfile vendor bundling).
Description check	✅ Passed	The description covers all essential sections: problem summary, specific fixes, context, and test verification. However, the required checklist items are not explicitly marked.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch fix/docker-publish-ci

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b96a0b7 and 6631df3.

📒 Files selected for processing (4)

.github/workflows/release.yml
apps/coordinator/Containerfile
apps/docker-provider/Containerfile
apps/kubernetes-provider/Containerfile

🧰 Additional context used

🧠 Learnings (7)

📓 Common learnings

Learnt from: nicktrn
Repo: triggerdotdev/trigger.dev PR: 2195
File: .github/workflows/release-helm.yml:42-46
Timestamp: 2025-06-25T13:24:23.836Z
Learning: In .github/workflows/release-helm.yml, the user nicktrn confirmed that using 'entrypoint' with 'docker://' steps works fine, contrary to previous analysis suggesting it's unsupported.

📚 Learning: 2026-01-15T11:50:06.067Z

Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-15T11:50:06.067Z
Learning: Run commands from root with `pnpm run` in this pnpm 10.23.0 monorepo using Turborepo

Applied to files:

apps/kubernetes-provider/Containerfile
apps/coordinator/Containerfile
apps/docker-provider/Containerfile

📚 Learning: 2025-11-27T16:26:44.496Z

Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/executing-commands.mdc:0-0
Timestamp: 2025-11-27T16:26:44.496Z
Learning: Execute most monorepo commands using `pnpm run` from the root directory, with `--filter` flag for specific packages (e.g., `pnpm run dev --filter webapp`)

Applied to files:

apps/kubernetes-provider/Containerfile
apps/docker-provider/Containerfile

📚 Learning: 2025-02-10T10:56:31.402Z

Learnt from: zvictor
Repo: triggerdotdev/trigger.dev PR: 1686
File: packages/build/src/extensions/python.ts:110-116
Timestamp: 2025-02-10T10:56:31.402Z
Learning: In Docker build contexts for Trigger.dev extensions, avoid over-engineering security measures when handling user-provided configuration (like Python requirements) as the build context is already isolated and the content is user-controlled.

Applied to files:

apps/docker-provider/Containerfile

📚 Learning: 2025-02-10T10:54:17.345Z

Learnt from: zvictor
Repo: triggerdotdev/trigger.dev PR: 1686
File: packages/build/src/extensions/python.ts:85-87
Timestamp: 2025-02-10T10:54:17.345Z
Learning: In Python-related Dockerfiles for trigger.dev, avoid adding explicit Python version pinning as the base image already provides conservative version management. Additional pinning would unnecessarily slow down builds.

Applied to files:

apps/docker-provider/Containerfile

📚 Learning: 2026-01-15T11:50:06.067Z

Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-01-15T11:50:06.067Z
Learning: Start Docker services with `pnpm run docker` (PostgreSQL, Redis, Electric)

Applied to files:

apps/docker-provider/Containerfile

📚 Learning: 2025-11-27T16:27:35.304Z

Learnt from: CR
Repo: triggerdotdev/trigger.dev PR: 0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-11-27T16:27:35.304Z
Learning: Run `npx trigger.devlatest dev` to start the Trigger.dev development server

Applied to files:

apps/docker-provider/Containerfile

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (27)

GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
GitHub Check: sdk-compat / Node.js 22.12 (ubuntu-latest)
GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
GitHub Check: sdk-compat / Bun Runtime
GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
GitHub Check: sdk-compat / Cloudflare Workers
GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
GitHub Check: sdk-compat / Deno Runtime
GitHub Check: typecheck / typecheck
GitHub Check: sdk-compat / Node.js 20.20 (ubuntu-latest)
GitHub Check: Analyze (javascript-typescript)

🔇 Additional comments (5)

apps/kubernetes-provider/Containerfile (1)

34-34: LGTM!

The two-step build sequence correctly ensures vendored files from @trigger.dev/core are in place before build:bundle runs. The && chaining properly short-circuits on failure, and combining both commands in a single RUN keeps the layer count down. Consistent with the same fix in the coordinator and docker-provider Containerfiles.

apps/docker-provider/Containerfile (1)

34-34: LGTM!

Same consistent fix as the other Containerfiles — vendor step before bundle step, chained with &&.

apps/coordinator/Containerfile (1)

38-38: LGTM!

Consistent with the other two Containerfiles. Vendor step correctly precedes the bundle step.

.github/workflows/release.yml (2)

125-131: Kept the tag push for traceability — good practice.

The v.docker.* tag is still pushed even though it no longer triggers the publish workflow. This preserves a reference trail in git, which is useful for auditing which commits were released as Docker images. Clear intent.

132-141: Clean workaround for the GITHUB_TOKEN workflow-trigger limitation.

The approach of using a direct workflow_call is the standard solution for this well-known GitHub Actions limitation. The if guard, secrets: inherit, and image_tag parameter all look correct. The publish.yml workflow has the corresponding workflow_call trigger with image_tag properly defined as a required string input, and it's consumed correctly by the downstream jobs.

_{✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.}

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

devin-ai-integration

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 4 additional findings.

nicktrn changed the title ~~fix(ci): fix Docker image publishing and worker builds~~ fix(ci): fix docker image publishing and worker builds Feb 6, 2026

myftija approved these changes Feb 6, 2026

View reviewed changes

devin-ai-integration bot reviewed Feb 6, 2026

View reviewed changes

nicktrn merged commit e536d35 into main Feb 6, 2026
64 checks passed

nicktrn deleted the fix/docker-publish-ci branch February 6, 2026 13:56

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(ci): fix docker image publishing and worker builds#3013

fix(ci): fix docker image publishing and worker builds#3013
nicktrn merged 1 commit intomainfrom
fix/docker-publish-ci

nicktrn commented Feb 6, 2026 •

edited by devin-ai-integration bot

Loading

Uh oh!

changeset-bot bot commented Feb 6, 2026

Uh oh!

coderabbitai bot commented Feb 6, 2026 •

edited

Loading

Uh oh!

devin-ai-integration bot left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

nicktrn commented Feb 6, 2026 • edited by devin-ai-integration bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Context

Test plan

Uh oh!

changeset-bot bot commented Feb 6, 2026

⚠️ No Changeset found

Uh oh!

coderabbitai bot commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Estimated code review effort

Uh oh!

devin-ai-integration bot left a comment

Choose a reason for hiding this comment

✅ Devin Review: No Issues Found

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nicktrn commented Feb 6, 2026 •

edited by devin-ai-integration bot

Loading

coderabbitai bot commented Feb 6, 2026 •

edited

Loading