chore(docs): improve version pinning advise to use installed trigger.dev CLI #2466
Conversation
|
WalkthroughDocumentation in docs/github-actions.mdx was updated to change CLI usage guidance: instruct adding trigger.dev as a devDependency and using direct CLI commands in package.json scripts (e.g., "trigger deploy" and "trigger deploy --env staging"), specifying version "4.0.2". A multi-line Tip about self-hosting flags was replaced with a single-line element. A YAML workflow snippet demonstrating a "Deploy Trigger.dev" step was removed. Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes ✨ Finishing Touches🧪 Generate 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/github-actions.mdx (2)
19-47: Use the pinned local CLI in the prod workflow (replace npx + add npm ci).The goal is to avoid floating versions in CI. Update the example to call your package.json script (which uses the locally installed CLI) and use npm ci for reproducible installs.
- name: Install dependencies - run: npm install + run: npm ci - name: 🚀 Deploy Trigger.dev env: TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }} run: | - npx trigger.dev@latest deploy + npm run deploy:trigger-prod
49-76: Same for staging: prefer local CLI via script and npm ci.- name: Install dependencies - run: npm install + run: npm ci - name: 🚀 Deploy Trigger.dev env: TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }} run: | - npx trigger.dev@latest deploy --env staging + npm run deploy:trigger
🧹 Nitpick comments (4)
docs/github-actions.mdx (4)
80-80: Tighten wording to reference scripts, not raw npx.“To your existing file” step should say to call the npm script (deploy:trigger[-prod]) to ensure version pinning.
104-104: Clarify version-sync sentence.Minor wording cleanup and make the failure mode explicit.
-The CLI and `@trigger.dev/*` package versions need to be in sync with the `trigger.dev` CLI, otherwise there will be errors and unpredictable behavior. Hence, the `deploy` command will automatically fail during CI on any version mismatches. +The `trigger.dev` CLI and all `@trigger.dev/*` packages must be pinned to the same version. The `deploy` command will fail in CI if any mismatch is detected.
105-105: Use a Tip component for consistency with other callouts.-Tip: add the `trigger.dev` CLI to your `devDependencies` and the deploy command to your `package.json` file to keep versions managed in the same place. For example: +<Tip>Add the `trigger.dev` CLI to `devDependencies` and a deploy script to `package.json` so CI uses the same version you use locally.</Tip> +For example:
39-41: CI best practice: prefernpm ciovernpm install.Improves determinism and speed in CI.
- - name: Install dependencies - run: npm install + - name: Install dependencies + run: npm ciAlso applies to: 68-70, 166-167
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
docs/github-actions.mdx(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: docs/docs.json:179-183
Timestamp: 2025-06-06T16:54:23.316Z
Learning: In the docs.json configuration for the Trigger.dev documentation (Mintlify system), both "tags": ["v4"] and "tag": "v4" properties can be used together and work correctly, even though this behavior is undocumented and may not work in local development environments.
📚 Learning: 2025-08-18T10:07:17.368Z
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-08-18T10:07:17.368Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Import Trigger.dev APIs from "trigger.dev/sdk/v3" when writing tasks or related utilities
Applied to files:
docs/github-actions.mdx
⏰ 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). (1)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (1)
docs/github-actions.mdx (1)
121-127: LGTM: this correctly uses the script (local, pinned CLI).
| "deploy:trigger-prod": "trigger deploy", | ||
| "deploy:trigger": "trigger deploy --env staging" | ||
| }, | ||
| "devDependencies": { | ||
| "trigger.dev": "4.0.2" | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Also pin your @trigger.dev/* packages to the same version as the CLI.
The deploy step will fail if app packages and CLI differ. Expand the example to make this explicit.
{
"scripts": {
"deploy:trigger-prod": "trigger deploy",
"deploy:trigger": "trigger deploy --env staging"
},
- "devDependencies": {
- "trigger.dev": "4.0.2"
- }
+ "devDependencies": {
+ "trigger.dev": "4.0.2"
+ },
+ "dependencies": {
+ "@trigger.dev/sdk": "4.0.2"
+ }
}Optionally add install commands right below the snippet:
npm i -D trigger.dev@4.0.2 && npm i @trigger.dev/sdk@4.0.2🤖 Prompt for AI Agents
In docs/github-actions.mdx around lines 110 to 115, the example shows only the
trigger.dev CLI pinned but doesn’t instruct to pin @trigger.dev/* packages to
the same version; update the example and accompanying text to explicitly state
that all @trigger.dev packages must match the CLI version to avoid deploy
failures, expand the shown package.json snippet to include a pinned @trigger.dev
SDK version matching trigger.dev@4.0.2, and add the optional install command
line shown in the comment directly below the snippet (e.g., an npm i -D
trigger.dev@4.0.2 && npm i @trigger.dev/sdk@4.0.2) so users can easily apply the
pins.
| <Tip> | ||
| If you're self-hosting v4, the `--self-hosted` and `--push` flags are **NOT** needed. | ||
| </Tip> | ||
| <Tip>If you're self-hosting v4, the `--self-hosted` and `--push` flags are **NOT** needed.</Tip> |
There was a problem hiding this comment.
Contradiction: Tip says flags NOT needed on v4, but example still uses them.
Self-hosted v4 should not pass --self-hosted/--push per the Tip. Align the example and also use the local CLI via script.
- name: 🚀 Deploy Trigger.dev
env:
TRIGGER_ACCESS_TOKEN: ${{ secrets.TRIGGER_ACCESS_TOKEN }}
# required when self-hosting
TRIGGER_API_URL: ${{ secrets.TRIGGER_API_URL }}
- # deploy with additional flags
- run: |
- npx trigger.dev@latest deploy --self-hosted --push
+ # deploy using the pinned local CLI (no extra flags on v4)
+ run: |
+ npm run deploy:triggerAlso applies to: 182-190
🤖 Prompt for AI Agents
docs/github-actions.mdx lines 140 and 182-190: The Tip states that for
self-hosted v4 the --self-hosted and --push flags are NOT needed, but the
example still uses them and doesn't demonstrate using the local CLI via script;
update the example(s) to remove --self-hosted and --push when documenting
self-hosted v4 and replace the direct CLI invocation with a call to the local
CLI script (e.g., use the repository's ./scripts/cli or npm script) so the
example aligns with the Tip and shows the recommended local CLI usage.
No description provided.