Install precompiled extensions from GitHub release assets
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- github, node.js, typescript
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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):
- Fetch the release:
GET /repos/{owner}/{repo}/releases/latest, or a specific tag viaowner/[email protected]. - Pick an asset:
- Fast path, the
ghconvention: an asset named exactlyelastic-<name>-<os>-<arch>[.exe].ghusesgh-<name>-<os>-<arch>[.exe], e.g.gh-whoami-windows-amd64.exeandgh-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 prefergnuovermusl(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.
- Fast path, the
- Download into
~/.elastic/extensions/elastic-<name>/. Release asset downloads redirect to another host, so this cannot reuseredirect: 'error'fromsearch.ts. Allow redirects for the asset URL only, without forwarding the GitHub token. - Extract
.tar.gz/.tgz/.zipif needed. The CLI's runtime dependencies currently include no archive library, so either add a small one or shell out to a systemtar/unzipwith an explicit argv, like the existingcross-spawnusage. A bare binary needs no extraction. - Find the entrypoint: an executable named
elastic-<name>[.exe]anywhere in the extracted tree.chmod +xon POSIX. Keep the existing realpath containment check. - Verify (optional): if the release has a
SHA256SUMS-style file, check the downloaded asset against it. - 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 (
optionalDependenciesper OS/CPU, with a JS shim): works with the existingnpm: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 (
--helpis not passed to extensions), found while building the same extension
authored by Pi Coding Agent (Claude Opus 4)
- 主要语言
- TypeScript
- 星标
- 51
- 派生
- 27
- 平均合并
- 1 天 19 分钟
- 30 天内合并 PR
- 50
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
elastic/cli 的其他 Issue
-
tracking
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
feat: ship skills/elastic/SKILL.md for agent invocation可能已有人在做 @onatozmenn 于 26 天前认领。 未关闭enhancement
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Stale
难度 3/5 1-2 天 新手友好度 38/100
维护者通常 1 天内回复
-
refactor(config): drop unused safeParse wrappers and stale Zod comments in config/schema.ts可能已有人在做 @JoshMock 于 7 天前认领。 未关闭Stale
难度 3/5 半天 新手友好度 62/100
维护者通常 1 天内回复
相似的 Issue
-
level/task type/bug
难度 2/5 1-3 小时 新手友好度 75/100
wazuh/wazuh-dashboard-plugins#9508 ·
维护者通常 1 天内回复
-
Testnet EOL page links Zonescan mainnet可能已有人在做 @napelvs 今天认领。 未关闭
难度 1/5 1 小时以内 新手友好度 76/100
-
难度 2/5 1-3 小时 新手友好度 78/100
Azure-Samples/azure-search-openai-demo#3249 ·
维护者通常 1 天内回复
-
[Docs] docs/architecture.mermaid leaves out 21 of the 51 src/ directories可能已有人在做 @uyg7x 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复
-
enhancement status:needs-triage
难度 2/5 1-3 小时 新手友好度 68/100
dongdongbh/Mindwtr#1438 ·
维护者通常 1 天内回复