[Bug]: version latest with download-repository can install a stale CLI

Inizia da getCliUrl, dove latest viene mappato a [RELEASE], e segui il percorso del repository di download e i relativi test esistenti. Esamina come vengono gestiti gli elenchi dei repository, il filtraggio per OS/architettura, l’ordinamento semver, l’autenticazione e il comportamento di fallback. Il lavoro è completo quando è disponibile una risoluzione opt-in e retrocompatibile di latest in una versione immutabile, senza nuovi errori né chiamate di rete obbligatorie, con copertura per i contenuti [RELEASE] memorizzati nella cache e per le modalità di repository descritte.

Describe the bug

version: latest combined with download-repository can keep installing an old JFrog CLI indefinitely.

latest is translated to [RELEASE], and [RELEASE] is part of the artifact path, so the action requests:

{artifactory}/{download-repository}/v2/[RELEASE]/jfrog-cli-<os-arch>/jfrog

A remote repository caches artifacts by the path it resolved. For a concrete version such as v2/2.123.0/... that is exactly what you want: the artifact is immutable, so caching it is a pure win. For a moving tag it breaks, and the Artifactory cache settings do not rescue it:

• Store Artifacts Locally is enabled by default, so the resolved binary is cached under the literal v2/[RELEASE]/... path.
• Metadata Retrieval Cache Period does not apply. Per the remote repository docs, that period is "relevant for artifacts that expire after a period of time", while "most downloaded artifacts do not change and this setting does not affect them". A CLI binary is one of those artifacts that do not change.
• Zapping the cache does not help either: per the same docs, "immutable binaries are not invalidated".
• Unused Artifacts Cleanup Period is empty by default, which means artifacts are "stored indefinitely" — and a binary a CI pipeline downloads on every run is never "unused" anyway.

So the first version resolved through that path can be served as latest forever, with no error and no obvious way for the user to notice.

Current behavior

- uses: jfrog/setup-jfrog-cli@v4
  with:
    version: latest
    download-repository: jfrog-cli-remote

Requests keep succeeding and the download URL looks correct, so nothing signals a problem.

Observed: a runner installed jf 2.91.0 while 2.123.0 was already published, and CI failed a minimum-version check with an error that gives no hint about the cached tag. Requesting the same latest directly from https://releases.jfrog.io/artifactory/jfrog-cli returned 2.123.0.

Reproduction steps

1. Create a generic remote repository proxying https://releases.jfrog.io/artifactory/jfrog-cli, leaving Store Artifacts Locally enabled and Unused Artifacts Cleanup Period empty (both defaults).
2. Run setup-jfrog-cli with version: latest and download-repository set to that repository, so v2/[RELEASE]/... is cached.
3. Wait for a newer CLI release and run the same workflow again.
4. The cached version is installed again, not the newer release.

Expected behavior and compatibility requirements

latest should not depend on a cached moving tag. Because this action runs in a very large number of workflows, the fix must not introduce new failures.

1. Preserve existing successful workflows by default. Do not newly reject or fail latest + download-repository.
2. Never request a moving tag through a repository that caches artifacts. Resolve a concrete X.Y.Z and download v2/X.Y.Z/..., so every version is cached under its own immutable path.
3. Keep all downloads inside download-repository when it is set. Never fall back to the public internet, because the runner may have no Internet access.
4. Do not assume every download-repository is a connected proxy. It may have Store Artifacts Locally disabled (direct streaming, no cache), be marked Offline, or be a repository whose content administrators manage themselves.
5. Prefer a backward-compatible, opt-in rollout until the new resolution is proven against connected proxies, cache-only repositories, and self-managed repositories.
6. When selecting a version, filter for the current OS/architecture, sort with semver rather than lexically (2.91.0 sorts above 2.123.0 as a string), and keep the current download path if resolution yields nothing. Note that folder listing through a remote reflects repository content, and on generic remotes it depends on List Remote Folder Items, which is API-only — so it is not automatically "newest on origin".
7. Tests must prove no new throw, core.setFailed, non-zero exit, authentication call, or additional required network call on the existing path, and must cover a repository that already has an old version cached under v2/[RELEASE].

Until then the safe guidance is a concrete version: X.Y.Z whenever download-repository is used.

Setup JFrog CLI version

v4.10.1 / current master (getCliUrl maps latest to [RELEASE])

JFrog CLI version

latest

Workflow operating system type and version

Not OS specific — any runner using latest through a caching repository can be served the cached version.

JFrog Artifactory version (if relevant)

Any remote repository proxying releases.jfrog.io/artifactory/jfrog-cli with default cache settings.

JFrog Xray version (if relevant)

N/A

Follow-up (non-failing mitigation)

#346 documents this behavior and adds a plain core.info line. It does not change URL construction, authentication, downloading, caching, exit status, or failure behavior.