feat(JFrogCliV2): allow persisting and reusing JFrog CLI config across steps

[SierraNL]

Reasons

I created this PR as an implementation of my feature request #636

It is a combination of a few features, if you prefer seperate PR's I can split it up.

But together they give the option of doing a big migration to JFrog a lot easier, by just adding the task in the front of the pipeline, and in the end to gather and push the buildinfo and keep the rest of the pipeline in place.

Summary

• Adds opt-in inputs to JFrogCliV2 so downstream pipeline steps (e.g. dotnet restore) can reuse the CLI config this task creates, instead of every step needing its own JFrog Platform service connection.
• registerInPath (default false) — adds jf's directory to the agent's PATH for later steps.
• keepConfig (default false) — skips the cleanup step so the config survives after this task finishes.
• configurationName (optional) — reuse an existing named config instead of creating a new one; jfrogPlatformConnection becomes optional when this is set (the task fails clearly if neither is provided).
• enablePackageAlias / packageAliasTools (default false) — installs JFrog CLI's package-alias ("Ghost Frog") shims (requires CLI ≥ 2.93.0; warns and skips on older versions) so native build tool calls route through jf for the rest of the job.
• The resolved config name is exposed via the JFROG_CLI_CONFIG_NAME pipeline variable, intended for a paired "teardown" task at the end of the pipeline (configurationName=$(JFROG_CLI_CONFIG_NAME), keepConfig=false) to delete the persisted config.
• Added minSupportedPackageAliasCliVersion (2.93.0) constant to jfrog-tasks-utils/utils.js, following the existing minSupported*CliVersion pattern.

All new behavior is off by default, so existing pipelines using JFrogCliV2 are unaffected.

Test plan

• node --check on tasks/JFrogCliV2/jfrogCliRun.js and jfrog-tasks-utils/utils.js
• Validated tasks/JFrogCliV2/task.json parses as valid JSON
• Formatted all changed files with the project's Prettier config (.prettierrc)
• Manual pipeline verification:
  • Default run (all new inputs at default) behaves identically to before
  • Setup/teardown pair: setup with configurationName empty, keepConfig=true, registerInPath=true; teardown with configurationName=$(JFROG_CLI_CONFIG_NAME), keepConfig=false
  • enablePackageAlias=true on a CLI version below 2.93.0 logs a warning and the task still succeeds

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[SierraNL]

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

[fluxxBot]

I think it would be better to split this into multiple PRs, as you’ve already mentioned in the description. There are a few independent changes here, and separating them would make the review easier and help us focus on one piece of functionality at a time.

Could you split the PR into logical, separate PRs?

I see that the tests are failing, can you please take a look at them too?
Also, Please add relevant tests as well.

[SierraNL]

Splitting this into 3 independent PRs per the review feedback above - each is a separate, self-contained slice of this diff and can be reviewed/merged in any order:

• feat(JFrogCliV2): add option to register JFrog CLI on agent PATH #650 - registerInPath (add JFrog CLI to agent PATH)
• feat(JFrogCliV2): allow persisting and reusing JFrog CLI config across steps #651 - persist & reuse JFrog CLI config across steps (configurationName, keepConfig, JFROG_CLI_CONFIG_NAME) - the core scenario from Using a JFrog CLI first approach, current tasks make it needlessly hard #636
• feat(JFrogCliV2): add Package Alias (Ghost Frog) support #652 - Package Alias ("Ghost Frog") support (enablePackageAlias, packageAliasTools)

Each now has an integration test under tests/resources/ following the existing test pattern (there was previously no coverage for JFrogCliV2 at all).

On the CI failures: they're not test failures in the code - the Tests workflow is a pull_request_target workflow gated behind a safe to test label, and for fork PRs GitHub always runs the base branch's copy of that workflow file rather than the PR's (a built-in security control), so this needs a maintainer to apply the label on each of the new PRs for the tests to actually run.

Closing this one in favor of the split PRs.

🤖 Generated with Claude Code