Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#805 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
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時間
マージ済み PR（30日）
61

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

elastic/cli のほかの issue

elastic/cli の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。