fix(cli): ensure --profile option displays correct profile name
Summary
Fixes an issue where the CLI --profile option was displaying the wrong profile name in command output.
Fixes #2542
Problem
When using --profile myprofile, the CLI would still display "profile: personal" or "profile: default" in the command output instead of showing the actual profile being used. This created confusion as users couldn't tell if their specified profile was actually being used.
Solution
- Added
profileToUsevariable that correctly resolves the profile name at the start of thewhoAmIfunction - Uses
readAuthConfigCurrentProfileName()for proper default profile resolution when no--profileis specified - Ensures all messages (intro, error, and output) display the same profile consistently throughout execution
Changes
Modified packages/cli-v3/src/commands/whoami.ts:
- Added import for
readAuthConfigCurrentProfileNamefromconfigFiles.js - Introduced
profileToUsevariable that resolves to either the specified profile or the current default - Updated all profile references throughout the function to use
profileToUseconsistently
Testing
The fix ensures correct profile display in all scenarios:
trigger.dev whoami- correctly shows the current profile from configtrigger.dev whoami --profile myprofile- correctly shows "myprofile"- Error messages now accurately reference the profile being used
Related Issues
Fixes #2542 - CLI displays incorrect profile name when using --profile option
⚠️ No Changeset found
Latest commit: 5173721ed1e08ff6122e4cf302ec32dc27f5df0d
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
Walkthrough
Multiple CLI command files were updated to pass an optional profile argument to printInitialBanner and printStandloneInitialBanner. The initialBanner utility API was changed to accept an optional profileOption and forwards it to getProfileInfo, which now accepts profileOption. Most call sites only add the profile parameter without other behavioral changes. Separately, the deploy command's failDeploy handling added INSTALLING to the set of serverDeployment.status values treated like PENDING/DEPLOYING/BUILDING. No other public exports were added or removed.
Estimated code review effort
🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches
❌ Failed checks (4 warnings)
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Linked Issues Check | ⚠️ Warning | Based on the provided summaries, the code updates add an optional profile parameter to banner utilities and adjust calls to printInitialBanner but do not reflect the introduction of a profileToUse variable or explicit use of readAuthConfigCurrentProfileName within the whoami command; the objectives from issue #2542 require resolving the profile at command start and consistently using that value across all whoami messages, which is not clearly implemented. | Introduce explicit profile resolution at the top of the whoami function by importing and calling readAuthConfigCurrentProfileName, assign the result or the --profile input to a profileToUse variable, and update all banner and output calls to reference this resolved value so that the displayed profile matches the user’s intent as specified in issue #2542. |
| Out of Scope Changes Check | ⚠️ Warning | The raw summary indicates changes across multiple commands and the initialBanner utilities—such as analyze, deploy, dev, env, and others—that are unrelated to the objectives of issue #2542, which focus solely on correcting the profile display in the whoami command, so these additional updates fall outside the linked issue’s scope. | Restrict the pull request to only the whoami command and its immediate dependencies for resolving and displaying the profile name, and move any modifications to other commands or broad initialBanner API signature changes into a separate PR if needed for wider profile support. |
| Description Check | ⚠️ Warning | The description clearly articulates the summary, problem, solution, and testing steps but omits the repository’s required checklist, changelog, and screenshots sections and uses “Fixes #2542” instead of the template’s “Closes #2542” heading, so it does not follow the specified template. | Please add the “✅ Checklist” section with the contributing guide, title convention, and testing confirmations, include a “Changelog” section with a brief change summary, provide a “Screenshots” placeholder or images if applicable, and update the issue reference to use “Closes #2542” as specified by the template. |
| Docstring Coverage | ⚠️ Warning | Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. | You can run @coderabbitai generate docstrings to improve docstring coverage. |
✅ Passed checks (1 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title Check | ✅ Passed | The title succinctly summarizes the main change—fixing the CLI’s --profile display behavior—and follows the conventional commit style, making it clear to reviewers what the pull request addresses. |
✨ Finishing touches
- [ ] 📝 Generate Docstrings
🧪 Generate unit tests
- [ ] Create PR with unit tests
- [ ] Post copyable unit tests in a comment
📜 Recent review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between d89ac4f81dad82e3dcae52194321f6068313e1bb and 5173721ed1e08ff6122e4cf302ec32dc27f5df0d.
📒 Files selected for processing (1)
packages/cli-v3/src/commands/deploy.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code For TypeScript, we usually use types over interfaces Avoid enums No default exports, use function declarations
Files:
packages/cli-v3/src/commands/deploy.ts
🧬 Code graph analysis (1)
packages/cli-v3/src/commands/deploy.ts (1)
packages/cli-v3/src/utilities/initialBanner.ts (1)
printStandloneInitialBanner(65-84)
🔇 Additional comments (2)
packages/cli-v3/src/commands/deploy.ts (2)
148-149: Profile forwarded to bannerNice touch routing
options.profilethrough toprintStandloneInitialBanner—this keeps the deploy intro consistent with the other profile-aware messaging you added.
679-682: INSTALLING state handledAdding the
INSTALLINGbranch alongside the other in-flight statuses ensures we fail deployments consistently while that server-side transition is in progress. Looks good.
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.
Comment @coderabbitai help to get the list of available commands and usage tips.
Thanks @nicktrn . Does this fix the actual issue now?
Does this fix the actual issue now?
Looks like it might, have you tested it? :wink:
@hongkongkiwi thanks for the fix :)
Would you like to rebase the branch and get this merged? There is just a couple of comments left from Nick, and it should be ready to go.
Fixed in #2728