Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[Feature Request] Show active context and target deployment in interactive command output

未关闭
  • 哪里不对？
#805 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
node.js, typescript
领域
cli, developer-experience

调研方向

Start by locating the interactive command output and context selection paths, especially where --use-context is applied and where --json output is written. Check the existing CLI configuration and tests for output flags. Done means the selected context and target can be shown optionally while stdout, JSON, exit codes, and non-interactive behavior remain compatible; the issue does not identify specific files or tests.

由索引模型根据 Issue 内容生成。

描述

Problem

When managing multiple Elasticsearch and Kibana deployments using Elastic CLI, it is not immediately obvious which deployment a command is targeting.

In our environment, engineers manage multiple customer deployments across several Elastic Cloud Enterprise (ECE) installations and self-managed Elastic Stack clusters.

Each deployment can have multiple contexts with different privilege levels, such as read-only and write-capable API keys.

This makes context awareness particularly important for operational safety.

Currently, the user must explicitly check the active context using elastic config current-context get or elastic status.

Proposed solution

Provide an optional context header for interactive command execution.

For example:

Elastic CLI
Context:    ece-eu01-customer-a-pr-01-ro
Target:     customer-a-pr-01
Endpoint:   https://es.example.com:9243
Access:     ro

[
  {
    "id": "dashboard-123",
    "title": "Infrastructure Overview"
  }
]

The header should show:

  • Effective context name.
  • Target Elasticsearch, Kibana or Cloud endpoint.
  • Optional human-readable deployment name or alias.
  • Configured permission profile, if explicitly available.

The context should reflect the context actually selected for the command, including --use-context, rather than simply displaying the default context.

Output compatibility

Preserving machine-readable output is essential.

Suggested behavior:

  • Disabled by default in non-interactive sessions.
  • Enabled optionally through a configuration setting or --show-context flag.
  • Display the header on stderr, leaving stdout unchanged.
  • Preserve valid JSON output when using --json or piping to jq.
  • Preserve existing exit codes and command behavior.
  • Support --no-context-header to suppress the header explicitly.

An alternative would be an interactive-only startup banner controlled by the existing CLI configuration.

Example configuration

output:
  context_header: interactive

Possible values:

  • never
  • interactive
  • always

The configuration syntax is only illustrative.

Additional considerations

The CLI should not infer actual privileges solely from context names like ro and rw. These names are conventions, not authorization guarantees.

An optional display label could be useful for long context names.

The feature should not require additional API requests just to print the header.

Environment

  • Elastic CLI v0.7.0
  • Rocky Linux 9.8
  • Node.js 24
  • Multiple Elastic Stack 9.x deployments
  • ECE and self-managed clusters
  • Named contexts using separate RO/RW API keys

Motivation

This would improve usability and reduce the risk of executing commands against an unintended customer or environment, without requiring shell wrappers or custom Bash prompt modifications.

主要语言
TypeScript
星标
53
派生
28
平均合并
4 天 12 小时
30 天内合并 PR
61

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

elastic/cli 的其他 Issue

查看 elastic/cli 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。