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

Install precompiled extensions from GitHub release assets

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

Maintainer thường phản hồi trong vòng 1 ngày

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
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github, node.js, typescript
Lĩnh vực
cli, developer-experience

Hướng nghiên cứu

Start with src/extension/installer.ts to follow the current GitHub install flow and entrypoint lookup; read the extension RFC at #222 for the related open question. Then trace how extensions are registered and upgraded, and check the existing cross-spawn usage before evaluating release downloads and archive extraction. Done means installing a GitHub release asset selects a matching platform asset, extracts it when needed, finds and registers the executable, and supports the proposed release source for upgrades.

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

Mô tả

tracking

Summary

Let elastic extension install owner/repo install a precompiled extension from the repository's GitHub release assets: detect the OS and CPU architecture, download the matching asset, extract it if it is an archive, and register the executable. This would be a deliberately small, naive version of what gh and mise's GitHub backend already do.

Motivation

Today a GitHub install does a shallow clone, then npm install --production --ignore-scripts if there is a package.json, and looks for an entrypoint in package.json bin or an executable named elastic-<name> in the root, bin/, or dist/ (src/extension/installer.ts). With no build step and --ignore-scripts, a compiled extension (Rust, Go, Zig, …) has only two options: commit binaries for every platform to the repo, or ask users to download a release asset by hand and run elastic extension create <name> --path <dir>.

I hit this while building a Rust extension. The extension contract (spawn an executable, pass the context in ELASTIC_* env vars) is language-agnostic, so the install path is the only part that assumes Node or committed files.

The RFC left this open: "Is there a preference for a compiled binary convention vs. allowing script-based extensions (like gh supports both)?" (#222, open question 4).

Proposal

When a GitHub install finds no entrypoint after cloning (or, alternatively, before cloning, when the latest release has matching assets):

  1. Fetch the release: GET /repos/{owner}/{repo}/releases/latest, or a specific tag via owner/[email protected].
  2. Pick an asset:
    • Fast path, the gh convention: an asset named exactly elastic-<name>-<os>-<arch>[.exe]. gh uses gh-<name>-<os>-<arch>[.exe], e.g. gh-whoami-windows-amd64.exe and gh-whoami-linux-386.
    • Fallback, a naive mise-style score: tokenize asset names and prefer ones that match OS aliases (process.platform: linux; darwin ~ macos/apple; win32 ~ windows) and arch aliases (process.arch: x64 ~ amd64/x86_64; arm64 ~ aarch64), and a supported archive format. On Linux, optionally prefer gnu over musl (mise also scores the C library).
    • Skip checksum/signature files (*.sha256, SHA256SUMS, *.sig). Fail with the candidate list if nothing matches or there is a tie.
  3. Download into ~/.elastic/extensions/elastic-<name>/. Release asset downloads redirect to another host, so this cannot reuse redirect: 'error' from search.ts. Allow redirects for the asset URL only, without forwarding the GitHub token.
  4. Extract .tar.gz/.tgz/.zip if needed. The CLI's runtime dependencies currently include no archive library, so either add a small one or shell out to a system tar/unzip with an explicit argv, like the existing cross-spawn usage. A bare binary needs no extraction.
  5. Find the entrypoint: an executable named elastic-<name>[.exe] anywhere in the extracted tree. chmod +x on POSIX. Keep the existing realpath containment check.
  6. Verify (optional): if the release has a SHA256SUMS-style file, check the downloaded asset against it.
  7. Register as today, and record the release tag and source so elastic extension upgrade <name> can compare against the latest release instead of pulling.

Non-goals, to keep it lightweight: version ranges, multiple binaries per extension, build-from-source fallback, signature/provenance verification, and non-GitHub hosts.

Alternatives

  • npm platform packages (optionalDependencies per OS/CPU, with a JS shim): works with the existing npm: source, but every native extension has to publish N+1 npm packages and still depends on Node at runtime.
  • Committed binaries: works today with no CLI changes, but bloats the repo and needs a per-platform launcher.

Related

  • #222 (extension RFC, open question 4)
  • #795 (--help is not passed to extensions), found while building the same extension

authored by Pi Coding Agent (Claude Opus 4)

Ngôn ngữ chính
TypeScript
Star
51
Fork
27
Merge trung bình
1 ngày 19 phút
Pull request đã merge (30 ngày)
50

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 elastic/cli

Tất cả issue của elastic/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.