[SandipBajracharya]

What

Adds a self-contained GitHub Actions workflow (.github/workflows/deploy.yml) that auto-deploys to Trigger.dev's production environment on every merge to master, gated behind the existing Tests + Code Quality checks.

Closes OUT-4184 (QuickBooks repo only — see follow-ups).

How it works

On push to master, four jobs run:

• typecheck → yarn typecheck:test
• test → yarn test
• lint → yarn lint:check && yarn prettier:check
• deploy → needs: [typecheck, test, lint], runs yarn trigger:deploy

The three check jobs run in parallel; deploy only starts if all three pass. They mirror the existing test.yml / lint.yml so the deploy gate is fully self-contained (no cross-workflow status coupling — easier to copy to the other integration repos).

Sentry sourcemaps

The deploy job sets VERCEL_ENV=production, which flips the isProd branch in trigger.config.ts and uploads Sentry sourcemaps so production stack traces are readable. It passes SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN, NEXT_PUBLIC_SENTRY_DSN, plus TRIGGER_ACCESS_TOKEN and TRIGGER_PROJECT_ID.

Secrets

All six secrets already exist in the repo's Production GitHub Environment (scoped to master), which is why the deploy job declares environment: Production — environment-scoped secrets are only exposed to a job that names the environment.

Hardening / robustness

• concurrency: deploy-production with cancel-in-progress: false — queues deploys and preserves commit order.
• yarn install --immutable in all jobs — deployed deps provably match the lockfile.
• permissions: contents: read at workflow root.
• timeout-minutes: 20 on the deploy job.
• Fixed SENTRY_AUTHTOKEN → SENTRY_AUTH_TOKEN typo in .env.example.

Follow-ups (not in this PR)

• Apply the same workflow to the Xero and Dropbox integration repos, each with its own Production environment + secrets (distinct TRIGGER_PROJECT_ID).

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
quickbooks-sync	Building		Sep 15, 2026 6:51am UTC
quickbooks-sync (dev)	Ready	Preview	Sep 15, 2026 6:51am UTC

[linear-code]

OUT-4184

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge.

Findings

1.  deploy-production does not create a first-in, first-out queue. GitHub keeps only one pending run for a concurrency group and may replace it when another push arrives. With three quick merges, the middle workflow can be canceled before deploy , so this does not deploy every merge in commit order. Use a queue that records each commit, or state clearly that only the newest pending commit will deploy. ▶

Summary

Merges to master now run checks and deploy the Trigger.dev project to production when all checks pass. The workflow also supplies production Sentry settings and pins GitHub Actions to fixed commits.

• Runs type checks, tests, and linting in parallel before deployment.
• Deploys with production Trigger.dev and Sentry environment values.
• Uses immutable installs, deployment limits, and fixed action commits.
• Renames the example Sentry token to match the code.

Diagram

sequenceDiagram
    participant Git as Push to master
    participant Actions as GitHub Actions
    participant Checks as Typecheck, test, lint
    participant Trigger as Trigger.dev production
    Git->>Actions: Start workflow for commit
    Actions->>Checks: Run three checks in parallel
    alt A check fails
        Checks-->>Actions: Failure
        Actions--xTrigger: Skip deploy
    else All checks pass
        Checks-->>Actions: Success
        Actions->>Trigger: Run yarn trigger:deploy
    end
    opt Newer push arrives before completion
        Git->>Actions: Start newer workflow
        Actions--xActions: Cancel older workflow
    end

Loading

_{Reviews (2) · Last reviewed commit: "fix(OUT-4184): address Greptile review o..."}

[greptile-apps]

deploy-production does not create a first-in, first-out queue. GitHub keeps only one pending run for a concurrency group and may replace it when another push arrives. With three quick merges, the middle workflow can be canceled before deploy, so this does not deploy every merge in commit order. Use a queue that records each commit, or state clearly that only the newest pending commit will deploy.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[SandipBajracharya]

Switched to cancel-in-progress: true. Only the newest commit on master should deploy — an older in-flight run is superseded, and since master is linear the newer commit already contains the older one. A per-commit FIFO queue isn't a goal here.

[SandipBajracharya]

@greptileai review

[priosshrsth]

lgtm