Document stale latest CLI when using download-repository

[sverdlov93]

Overview

Related to #347. Does not close that issue. Tracking Jira: RTECO-2310.

version: latest is not resolved to a version number. It becomes the literal path segment [RELEASE] in the download URL (v2/[RELEASE]/jfrog-cli-.../jfrog). When the repository has Store Artifacts Locally enabled (the default), the binary returned for that path is cached under it, so later runs can keep receiving that same binary instead of a newer CLI. Caching is exactly right for a concrete version such as 2.123.0, where the path is immutable.

This PR documents that behavior and prints one plain core.info line. It does not change URL construction, authentication, downloading, caching, exit status, or failure behavior.

Details

• README: explain the cached v2/[RELEASE] path and recommend a concrete X.Y.Z (same tone in the version section and in the Artifactory download note).
• action.yml: same guidance on the version and download-repository inputs, phrased as a recommendation rather than a prohibition, since it only applies when the repository stores artifacts locally.
• Runtime: log only when both latest and download-repository are set. Pinned versions and direct public downloads stay unchanged and silent.
• Tests: cover the exact log/no-log branches.

Safety

The production TypeScript path adds two string comparisons and core.info, which writes a normal line to stdout. There are no new throws, core.setFailed, error/warning annotations, network requests, authentication calls, or changes to the CLI URL.

The generated lib/utils.js also picks up an existing TypeScript/JavaScript drift on master: setupPackageAliasIfRequested already used core.addPath in src/utils.ts, while compiled lib/utils.js still wrote GITHUB_PATH with appendFileSync. Recompiling aligns the published JS with source. That is not a new TypeScript behavior in this PR.

Follow-up: Auto-Build CI

Auto-Build-Publish is red for two independent reasons, neither from the docs/core.info change:

1. Setup Go / no go.mod (all OS since 2026-03-17) — install-go-with-cache@main after jfrog/.github#28 requires go.mod. This repo is a Node action. pull_request_target runs the master workflow YAML, so pinning go-version here does not fix the current labeled run until that YAML is on master or the shared action falls back (opened on jfrog/.github).
2. macOS local Artifactory (since 2025-09-02) — jobs ran ~23 minutes then exit 1, matching local-rt-setup's 1200s wait. Same skip as jfrog-cli (JGC-413). macos is omitted from the Auto-Build matrix so the job does not provision a runner that then no-ops (or hits gacts/run-and-post-run post).

This PR now also pins go-version: "1.24" (what local-rt-setup needs) on Auto-Build and Frogbot Scan Repository.

Real fix

Issue #347 / RTECO-2310 tracks resolving latest to a concrete version so each version is cached under its own immutable path, with the constraints that existing successful workflows must keep working and downloads must stay inside download-repository.

[sverdlov93]

About the red Auto-Build-Publish-Test check

That check is not failing because of this PR. It has been failing on master since 86dacb6 (2026-03-17); every push run since then is red, and all 6 matrix cells die on the same step:

Setup Go with cache
##[error]The specified go version file at: go.mod does not exist

Cause: jfrog/.github#28 changed install-go-with-cache so that when go-version is not passed it reads go-version-file: go.mod (previously it defaulted to go-version: "1.25" and read no file). This repository is a Node action with no go.mod, so actions/setup-go throws before anything else runs. local-rt-setup, which install-local-artifactory builds, still needs a Go toolchain, so the step cannot simply be dropped.

Fix in this PR (e86c3d9): pass go-version: "1.24" explicitly in auto-build-publish.yml and frogbot-scan-repository.yml.

Note on verification: Auto-Build-Publish-Test runs on pull_request_target, so GitHub uses the workflow definition from the base branch. This PR's own runs therefore still execute master's unpinned version and will stay red — you can see it in the last run, which still includes the macos cells this PR removes. The check can only go green after merge.

Independent evidence that the pinned form works with no go.mod present: jfrog/.github#33 adds a resolution matrix for install-go-with-cache (6 cases x ubuntu / windows / macos). The go-version-no-gomod case is exactly this scenario and installs Go 1.24 on all three runners.

The macos cells are removed from the matrix in the same commit for a separate, older reason: local Artifactory bootstrap on GitHub-hosted macOS has been broken since macos-latest moved to macOS 15 (first red 2025-09-02), where jobs hit the 1200s local-rt-setup wait and exit 1. jfrog-cli skips macOS for the same reason (JGC-413). Happy to move that hunk to its own PR if you would rather keep this one docs-only.

[agrasth]

Quick summary in plain terms, from a close read of this PR:

• This PR is docs + one log line only — it does not fix the actual bug in #347 (the stale latest CLI problem). That part of the code is confirmed unchanged, which matches what the PR description already says.
• The PR description says macOS was "removed" from the CI test matrix, but os: [ ubuntu, windows, macos ] (line 25) is actually unchanged — macOS is only skipped step-by-step with if checks, not excluded. So every run still spins up a macOS runner that does basically nothing before exiting, instead of not spinning one up at all.
• A few other things below, on the exact lines.

[github-actions]

---

🐸 JFrog Frogbot