Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#348 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, typescript
Lĩnh vực
ci-cd, devops, tooling

Hướng nghiên cứu

Bắt đầu trong src/utils.ts tại Utils.getAndAddCliToPath() và loadFromCache(), sau đó kiểm tra cacheAndAddPath() và cleanup.ts để theo dõi cách các phiên bản được lưu trong bộ nhớ đệm được ghi và đọc. Xem xét issue #282 liên quan và các lệnh gọi tool-cache hiện có trước khi quyết định hành vi phân giải phiên bản được hỗ trợ. Hoàn thành khi một CLI phù hợp được lưu trong bộ nhớ đệm, bao gồm latest hoặc một dải phiên bản hay phiên bản tối thiểu được yêu cầu, được sử dụng trước khi tải xuống, đồng thời fallback hiện tại vẫn hoạt động.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature request
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).

Ngôn ngữ chính
TypeScript
Star
267
Fork
111
Merge trung bình
10 phút
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jfrog/setup-jfrog-cli

Tất cả issue của jfrog/setup-jfrog-cli

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.