trigger.dev icon indicating copy to clipboard operation
trigger.dev copied to clipboard

fix(cli): ensure --profile option displays correct profile name

Open hongkongkiwi opened this issue 3 months ago • 5 comments

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 profileToUse variable that correctly resolves the profile name at the start of the whoAmI function
  • Uses readAuthConfigCurrentProfileName() for proper default profile resolution when no --profile is 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 readAuthConfigCurrentProfileName from configFiles.js
  • Introduced profileToUse variable that resolves to either the specified profile or the current default
  • Updated all profile references throughout the function to use profileToUse consistently

Testing

The fix ensures correct profile display in all scenarios:

  • trigger.dev whoami - correctly shows the current profile from config
  • trigger.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

hongkongkiwi avatar Sep 23 '25 09:09 hongkongkiwi

⚠️ 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

changeset-bot[bot] avatar Sep 23 '25 09:09 changeset-bot[bot]

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 banner

Nice touch routing options.profile through to printStandloneInitialBanner—this keeps the deploy intro consistent with the other profile-aware messaging you added.


679-682: INSTALLING state handled

Adding the INSTALLING branch 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.

❤️ Share

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

coderabbitai[bot] avatar Sep 23 '25 09:09 coderabbitai[bot]

Thanks @nicktrn . Does this fix the actual issue now?

hongkongkiwi avatar Sep 25 '25 12:09 hongkongkiwi

Does this fix the actual issue now?

Looks like it might, have you tested it? :wink:

nicktrn avatar Sep 25 '25 21:09 nicktrn

@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.

myftija avatar Nov 03 '25 09:11 myftija

Fixed in #2728

nicktrn avatar Dec 10 '25 17:12 nicktrn