Accept a JFrog CLI already present on the runner (version range / minimum version) instead of requiring an exact version match

Inizia da src/utils.ts, in Utils.getAndAddCliToPath() e loadFromCache(), poi esamina cacheAndAddPath() e cleanup.ts per tracciare come vengono scritte e lette le versioni memorizzate nella cache. Esamina l’issue #282 correlata e le chiamate esistenti a tool-cache prima di decidere il comportamento supportato per la risoluzione delle versioni. Il lavoro è completo quando, prima del download, viene usata una CLI memorizzata nella cache adatta, inclusi latest o un intervallo o un minimo richiesto, e il fallback esistente continua a funzionare.

Is your feature request related to a problem? Please describe.

On self-hosted runners we bake the JFrog CLI into the runner image and stage it in the tool cache at /opt/hostedtoolcache/{jf,jfrog}/<version>/x64. Despite that, the action downloads the CLI again unless a workflow pins version: to the exact string matching what is baked into the image.

The cause is in Utils.getAndAddCliToPath() (src/utils.ts, v5.1.0):

const isLatestVer: boolean = version === Utils.LATEST_CLI_VERSION;

if (!isLatestVer && lt(version, this.MIN_CLI_VERSION)) { ... }
if (!isLatestVer && this.loadFromCache(version)) {
    core.info('Found JFrog CLI in cache. No need to download');
    return;
}

and loadFromCache() passes the version straight to toolCache.find(name, version), which is an exact-version lookup.

Two consequences:

version: latest never consults the cache at all. The !isLatestVer guard skips loadFromCache() entirely, so the CLI is downloaded on every run. cacheAndAddPath() still writes the binary into the tool cache under the pseudo-version 100.100.100, but nothing in the setup path ever reads it back - only cleanup.ts calls loadFromCache() afterwards.

Pinning an exact version does avoid the download, but it couples every workflow to the runner image. When we bump the baked CLI from, say, 2.78.0 to 2.79.0, every workflow still pinning 2.78.0 starts downloading again, so each image bump has to be followed by a PR in every consuming repository. A newer CLI already present on the runner is never accepted — and the action's own default (version: 2.91.0) has the same effect for anyone who does not set the input.

For us this is wasted time to re-download CLI even we already have it.

Describe the solution you'd like to see

Resolve a satisfying CLI rather than only an identical one:

Support a semver range in version: (e.g. >=2.78.0, ^2.78, 2.x) and resolve it against what is already in the tool cache via toolCache.findAllVersions() before falling back to a download. This is the behaviour of actions/setup-node, setup-python and setup-go, so it is a familiar contract.

Make version: latest check the cache before downloading, instead of unconditionally skipping loadFromCache(). Today the 100.100.100 entry written by cacheAndAddPath() is write-only from the setup path's point of view.

Optionally, an input such as use-preinstalled: true that accepts an existing jf (from the tool cache or from PATH) when jf --version reports a version greater than or equal to the requested one, and only downloads if it is older.

Any one of these would let the runner image own the CLI version while workflows declare only a minimum, so bumping the image does not require editing every workflow.

Describe alternatives you've considered

• Pinning the exact version in every workflow. This is what we do today; it is exactly the coupling described above and it silently regresses to downloading whenever the runner image is updated.
• Staging both the jf and jfrog file names in the tool cache. Necessary anyway (see #282), but it does not help here - the version still has to match the workflow input exactly.
• Skipping the action and invoking the baked jf directly. This loses the OIDC/server configuration, the build-info publishing and the cleanup step, which is most of the value of the action.
• Pre-seeding the cache under the 100.100.100 pseudo-version to satisfy version: latest. Does not work, because the !isLatestVer guard means the lookup never runs.

Additional context

Observed with setup-jfrog-cli v5.1.0 on self-hosted Linux runners (Ubuntu 24.04, x64), CLI staged at /opt/hostedtoolcache/jf/<version>/x64 and /opt/hostedtoolcache/jfrog/<version>/x64 with the matching x64.complete markers.

Related: #282 (CLI is downloaded even when found in runner cache - jf cached but jfrog not).