Say which configuration jf setup changed and how widely it applies

[sverdlov93]

Overview

jf setup writes user-level package manager configuration, so a run inside one project silently changes dependency resolution for every other project that user builds. The only output was:

Successfully configured maven to use JFrog repository 'libs-virtual'.

That says nothing about which file changed or how far the change reaches. When an unrelated project later fails to resolve, the error comes from the package manager itself and names only the missing artifact — there is nothing to connect it back to a jf setup run in a different directory. This came out of a report where configuring Maven against a demo repository broke a different project that resolved against another Artifactory, with no warning that the two were linked.

Details

Adds a line after the success message naming the configuration that changed and stating that it applies beyond the current directory:

Successfully configured maven to use JFrog repository 'libs-virtual'.
This updated your user-level Maven settings (settings.xml), so it applies to every maven project for this user, not only the current directory.

Container logins are worded differently on purpose. docker, podman and helm authenticate to the platform rather than redirecting resolution — after jf setup docker, an unqualified docker pull alpine still goes to Docker Hub — so claiming their projects now resolve through Artifactory would be wrong:

Credentials were saved to your Docker credential store for your user account.

A package manager with no entry prints nothing rather than something vague.

Notes

• Deliberately not included: reporting what the previous value was (“was pointing at X, now Y”). That is the strongest version and would have prevented the reported incident outright, but it needs per-package-manager read-before-write, so it belongs in its own change.
• Companion change in jfrog-cli adds the same scope statement to jf setup --help, so the behaviour is discoverable before running the command as well as after.
• Three tests: every supported package manager has a note; container logins never claim resolution while resolution-changing managers always state the scope; an unknown package manager stays silent.
• TestSetupCommand_Pnpm fails on this machine both with and without this change (pnpm 11.17.0) — pre-existing and unrelated; every other test in the package passes.

Summary by CodeRabbit

• New Features
  • Setup now explains which user-level configuration area was updated for each supported package manager.
  • Container-based package managers clarify that credentials were saved through the container CLI.
  • Configuration messages distinguish settings that apply globally across projects from directory-specific changes.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 261ca905-8d22-4404-a4bc-9c40cf6bed8a

📥 Commits

Reviewing files that changed from the base of the PR and between 2227ac7 and b9e2779.

📒 Files selected for processing (2)

• artifactory/commands/setup/setup.go
• artifactory/commands/setup/setup_test.go

---

📝 Walkthrough

Walkthrough

Setup now generates package-manager-specific user-scope notes and prints them after successful configuration. Tests cover supported managers, container login behavior, and silent handling of unsupported managers.

Changes

Setup configuration scope notes

Layer / File(s)	Summary
Generate package-manager scope notes artifactory/commands/setup/setup.go	Maps supported package managers to configuration locations and distinguishes container-login managers when formatting scope notes.
Emit and validate scope notes artifactory/commands/setup/setup.go, artifactory/commands/setup/setup_test.go	Prints non-empty notes after successful setup and tests supported, container-login, and unsupported package-manager behavior.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant SetupCommand
  participant configScopeNote
  participant log.Output
  SetupCommand->>configScopeNote: package manager
  configScopeNote-->>SetupCommand: optional scope note
  SetupCommand->>log.Output: note when non-empty

Loading

Possibly related PRs

• jfrog/jfrog-cli-artifactory#503: Adds Apt support in the setup package-manager mappings extended by this scope-note logic.

Suggested labels: new feature

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly reflects the main change: jf setup now reports which configuration was updated and the scope of that change.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Fix failing CI checks

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch RTECO-0000-setup-state-config-scope

---

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

[sverdlov93]

Companion help-text change: jfrog/jfrog-cli#3627 — states the same scope in jf setup --help, so it is visible before running the command as well as in the output afterwards.

Worth noting GetAIDescription() already carried this for agents ("Configuration is applied globally to the package manager's native config … affecting all projects on the machine, not just the current one"), added when the command was un-hidden in jfrog/jfrog-cli#3626. These two changes bring the human-facing help and the command output in line with what agents were already told.

[sverdlov93]

Folded into #520 so both jf setup changes go through a single two-approval cycle rather than two.

The commit is carried over there unchanged, plus a review fix on top: the scope note claimed user-level scope unconditionally, but PIP_CONFIG_FILE (pip, pipenv), NPM_CONFIG_USERCONFIG (npm, pnpm), POETRY_CONFIG_DIR and UV_CONFIG_FILE can move the configuration off its user-level default — possibly into the current project — which made the claim wrong in exactly those cases. Those runs now report the actual path and the variable responsible instead.

Nothing is lost by closing this; #520 is the single PR to review.