[FEATURE_REQUEST] Ignore Violations For Specific Resources Using YAML Config File
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 28/100
調査の方向性
The request asks for a YAML-based alternative to the existing annotation method for ignoring a check on a specific resource, but the payload does not name the files involved. Start by finding where the annotation-based ignore is applied and whether a kube-linter.yaml config is already loaded. The design, including the config format, is still open, so agree on it in the thread first. Done means a named check is skipped for a named resource when the YAML entry is present, with the reason recorded.
索引モデルが issue の本文から書いたものです。
説明
Description of the problem/feature request
Currently the only way to ignore a violation for a specific check and a specific resource is via the annotation method. The problem is we pull through the public Helm Charts and deem them immutable to facilitate easier upgrades further down the line and in some cases the maintainers have not made annotations a configurable field from the values.yaml file.
An example would be a test Pod resource that does not contain a readinessProbe directive. We don't want to exclude this check completely as its important for the actual component, but would want to ignore for this specific Pod resource.
An option (might be others as well) could be to configure this in the YAML file, kube-linter.yaml, that is an add-on to the folder structure.
For example:
# Pattern
ignoreChecks:
<check-name>:
resources:
- name: <resource-name>
reason: <explanation>
# Example
ignoreChecks:
no-readiness-probe:
resources:
- name: component-A-service-test
reason: "Test pod does not require readiness probe"
The above is not absolute, its just a point of reference using the information one would supply via the annotation in a easy reusable way.
Description of the existing behavior vs. expected behavior
Existing behavior is this is not possible without altering the YAML resource file directly. Expected behavior is for a lint check to pass if able to ignore violations via the YAML configuration file.
Additional context
N/A
- 主要言語
- Go
- スター
- 3.5k
- フォーク
- 277
- 平均マージ
- 1日 22分
- マージ済み PR（30日）
- 7
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
stackrox/kube-linter のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
stackrox/kube-linter#1203 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
stackrox/kube-linter#824 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] Selector not matched if deployment and service are not in the same folder (`dangling-service`)対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
stackrox/kube-linter#1282 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] dangling-ingress fails to find referenced resource in a sibling directory対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 78/100
stackrox/kube-linter#1277 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] dangling-servicemonitor ignores the monitor namespace by default対応中かも @Eljees が 51 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 25/100
stackrox/kube-linter#1256 ·
メンテナーはふだん 1 日以内に返信
stackrox/kube-linter の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
GitHub webhook is not subscribed to release events, so `event: release` never triggers対応中かも @qsun が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
woodpecker-ci/woodpecker#7542 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
zilliztech/milvus-backup#1386 ·
メンテナーはふだん 1 日以内に返信
-
Pipelined flush no longer observes kill signals after #2042: flush backoffer is built with nil varsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信