feat: support JFROG_CLI_URL/ACCESS_TOKEN/USER/PASSWORD env fallbacks (#3490)

[mvanhorn]

Summary

Adds environment-variable fallbacks for the core connection details in CreateServerDetailsFromFlags:

• JFROG_CLI_URL -> --url
• JFROG_CLI_ACCESS_TOKEN -> --access-token
• JFROG_CLI_USER -> --user
• JFROG_CLI_PASSWORD -> --password

A flag value, when supplied, always wins over the corresponding environment variable; the environment variable is used only when the flag (and, for secrets, the --*-stdin path) is empty. When no flag and no env var are set, behavior is unchanged. This mirrors the existing JFROG_CLI_SERVER_ID env fallback that already lives in this same function.

The new variables are documented in docs/common/env.go and registered in GetGlobalEnvVars() so they appear in jf options/help output.

Why this matters

Issue #3490 asks for an env-only path to supply connection details so that pipelines and Docker-based CI can avoid repeating --url/--access-token on every jf invocation (and avoid putting credentials on the command line). The repo already has the exact precedent for this: ServerId falls back to os.Getenv(coreutils.ServerID) (JFROG_CLI_SERVER_ID) inside CreateServerDetailsFromFlags. This change extends that established pattern to the remaining connection fields, keeping the implementation small and consistent.

Behavior notes (intentional, for parity with the flags):

• JFROG_CLI_URL is treated exactly like --url: per-service URLs (Artifactory/Xray/Distribution) are derived from it by the existing domain switch in createServerDetailsFromFlags, so setting it to a platform base behaves identically to passing --url. No /artifactory auto-append is added.
• Like the flags today, supplying credentials via these env vars triggers the existing "credentials passed as options" path in CreateServerDetailsWithConfigOffer (credentialsChanged), i.e. command-supplied details and stored server config remain mutually exclusive. This is the same exclusivity already enforced for --access-token/--user/--password.

Testing

• Added TestCreateServerDetailsFromFlagsEnvFallback in utils/cliutils/utils_test.go, a table-driven test covering: env fallback for url/user/password/access-token, flag-wins-over-env precedence, trailing-slash handling on the URL, and the no-flag/no-env case (empty fields, no regression).
• gofmt -l clean on all changed files.
• go vet ./utils/... clean.
• go build ./... succeeds.
• go test ./utils/cliutils/... passes (including the new test).

Fixes #3490

AI was used for assistance.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[mvanhorn]

I have read the CLA Document and I hereby sign the CLA

[enaess]

Is there any movement on this merge? It would be a very welcoming change

[mvanhorn]

Thanks for the bump. Nothing is blocked on my side, so here is where it stands in case a maintainer sees this.

The change is complete and the CLA is signed. The only red check is scan-pull-request, and it did not fail on the code: the run shows 720h0m1s, which is GitHub's 30-day ceiling for a queued run, so it expired rather than executing. The usual cause for a fork PR is that security scans do not start until a maintainer approves the workflow run.

So the unblocking step is a maintainer approving or re-running the workflow on this PR. If the scan then finds something real I will fix it the same day.

If the feature itself needs a decision rather than a scan, happy to have that conversation instead. #3490 asked for JFROG_CLI_URL / JFROG_CLI_ACCESS_TOKEN / JFROG_CLI_USER / JFROG_CLI_PASSWORD to work as fallbacks and this implements that, but if the maintainers would rather shape it differently, say so and I will rework it.