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

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

Đang mở
  • Có gì không ổn?
#347 1 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ó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ 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

Hướng nghiên cứu

Bắt đầu từ getCliUrl, nơi latest được ánh xạ tới [RELEASE], rồi lần theo đường dẫn repository tải xuống và các bài kiểm thử hiện có của nó. Xem xét cách xử lý danh sách repository, việc lọc theo OS/kiến trúc, sắp xếp semver, xác thực và hành vi fallback. Hoàn thành có nghĩa là có cơ chế phân giải latest thành một phiên bản bất biến theo opt-in và tương thích ngược, không phát sinh lỗi mới hoặc các lệnh gọi mạng bắt buộc, cùng với độ bao phủ cho nội dung [RELEASE] được lưu trong bộ nhớ đệm và các chế độ repository được mô tả.

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

Mô tả

bug
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.

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.