fix(webapp): progress native self-hosted deployments instead of dead enqueue path

[flowq-C]

Summary

In self-hosted native deployments, deployments could remain stuck on PENDING or later TIMED_OUT because the expected build transition was not happening through the current enqueue path.

In our self-hosted reproduction, progressing the deployment was the action that actually moved the deployment forward and allowed the build/runtime flow to continue.

What changed

• replace the native self-hosted build transition call from enqueueBuild(...) to progressDeployment(...)

Why

• native self-hosted deployments already have the necessary deployment metadata
• the current enqueue behavior can leave deployments stuck without a real build transition

Real-world failure mode

• deployment initializes successfully
• deployment remains PENDING
• eventually deployment becomes TIMED_OUT

Notes

• this change is intentionally narrow
• it only targets the native self-hosted build transition path

Closes #3256

[changeset-bot]

⚠️ No Changeset found

Latest commit: 83bfbc8

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]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 383ddaa3-bef2-489f-b6c6-7ebc1fb55296

📥 Commits

Reviewing files that changed from the base of the PR and between 774007e and 83bfbc8.

📒 Files selected for processing (1)

• apps/webapp/app/v3/services/initializeDeployment.server.ts

---

Walkthrough

The change updates the native-build enqueue pathway in the deployment initialization service. Instead of calling deploymentService.enqueueBuild(), the code now calls deploymentService.progressDeployment() with a revised payload structure comprising contentHash, git metadata, runtime, and buildServerMetadata. The conditional logic, error handling, and deployment cancellation behavior remain structurally unchanged. Comments were updated to reflect that this operation transitions deployments out of PENDING state and initiates the local build path for self-hosted native builds.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

Hi @flowq-C, thanks for your interest in contributing!

This project requires that pull request authors are vouched, and you are not in the list of vouched users.

This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details.

[devin-ai-integration]

Devin Review found 0 potential issues.

View 2 additional findings in Devin Review.

[flowq-C]

Thanks for the quick signal.

We opened this PR while debugging multiple reproducible self-hosted deployment failures in a real Trigger.dev self-hosted setup.

Relevant linked issues:

• self-hosted v4.4.3 native deployments can stay stuck on PENDING because build enqueue is skipped #3256
• self-hosted local registry deployments can succeed without pushing the image, leading to No such image at runtime #3257
• self-hosted build indexer cannot fetch project env vars with runtime environment key and aborts local deployment build #3258
• self-hosted managed indexer treats env var lookup failure as fatal instead of degrading gracefully #3259

This PR is meant as a minimal proposed fix, not a drive-by feature change.

If external PRs require a vouch first, the practical ask is:

• either vouch the contributor so we can iterate normally
• or cherry-pick / re-apply the patch internally if you agree with the fix direction

We are happy to adjust the patch, split it further, or add a changeset if needed once there is a path for contribution.

[flowq-C]

Follow-up from live validation:

We continued debugging this against the same self-hosted installation and got the deploy path working end-to-end.

This PR still matches one of the real failure modes we saw early in the process:

• self-hosted native deployments could sit in PENDING / later TIMED_OUT

After repairing the full path, we successfully deployed newer versions and created background workers in the real self-hosted environment.

So even though this PR was auto-closed by contribution policy, the underlying failure mode was real in our repro and not just a local misread of deployment state.