Conversation
✅ Deploy Preview for flanksource-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for canarychecker canceled.
|
There was a problem hiding this comment.
Pull Request Overview
This PR updates several submodule references and enhances the documentation for notification silences by adding a detailed reference MDX and reorganizing the conceptual guide.
- Bump submodule commits in multiple
modules/*and the rootmission-control-chart - Introduce
_silence.mdxto document silence fields and resource selector schema - Revise
silences.mdxguide with an import, example fixture, and clearer sections on creation, filters, and recursion
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| modules/mission-control-registry | updated subproject commit |
| modules/mission-control-chart | updated subproject commit |
| modules/mission-control | updated subproject commit |
| modules/duty | updated subproject commit |
| modules/canary-checker | updated subproject commit |
| mission-control-chart | updated subproject commit |
| mission-control/docs/reference/notifications/_silence.mdx | new reference doc for silence API fields |
| mission-control/docs/guide/notifications/concepts/silences.mdx | restructured guide with import, example block, and sections |
Member
|
Can we add an example of a filter in a full spec. The selectors table also seems incomplete. |
moshloop
reviewed
May 30, 2025
adityathebe
force-pushed
the
docs/silences-crd
branch
from
e3a36a7 to
ed20f04
Compare
Member
Author
|
adityathebe
force-pushed
the
docs/silences-crd
branch
from
0d4f6eb to
05bb0e3
Compare
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
adityathebe
force-pushed
the
docs/silences-crd
branch
from
05bb0e3 to
4c2741b
Compare
adityathebe
force-pushed
the
docs/silences-crd
branch
from
4c2741b to
0464273
Compare
WalkthroughDocumentation for notification silences is expanded and clarified. A guide now covers concepts including resource selection, filtering, and recursive mode with creation methods. Reference documentation defines silence field schemas and adds new notification template variables (silenceURL, channel, groupedResources) across CheckHealth and ConfigEvents contexts. Changes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In `@mission-control/docs/guide/notifications/concepts/silences.mdx`:
- Around line 70-76: The image `silence-notification-form.png` under the
"Recursive Mode" heading is not illustrating recursive parent→child behavior;
move this image out of the "Recursive Mode" section and either place it under
the "Creating Silences" section or replace it with a new diagram that visually
depicts the parent→child relationship (namespace → deployments/statefulsets →
pods). Update the MDX around the "Recursive Mode" heading to reference the new
illustrative diagram (or add a caption) and ensure the image filename or alt
text clearly indicates whether it is the general creation form
(`silence-notification-form.png`) or the recursive relationship diagram.
- Around line 20-22: The YAML code fence in the MDX uses a non-existent file
reference and an empty title: update the code block in
mission-control/docs/guide/notifications/concepts/silences.mdx by either (a)
replacing
file=<rootDir>/modules/mission-control/fixtures/silences/silence-test-env.yaml
with a correct existing fixture path, (b) removing the file= directive and
pasting the YAML inline, or (c) deleting the whole code fence if not needed;
also remove the empty title="" or replace it with a meaningful label like
title="Example silence configuration", and delete the trailing space after the
closing backticks to ensure the block renders correctly.
In `@mission-control/docs/reference/notifications/_silence.mdx`:
- Around line 39-52: Update the Resource Selector block: rename the field key
"kind" to "types" in the Fields rows (the selector accepts resource type
patterns like "Kubernetes::Pod", "Kubernetes::*", "AWS::EC2::Instance"), and
either expand the rows to include the standard ResourceSelector fields (add
entries for namespace, labelSelector, tagSelector, id, health, statuses, etc.,
with brief descriptions and scheme types) or replace the rows with a single
sentence linking to the canonical ResourceSelector docs
(/docs/reference/resource-selector) if silences support the full API; ensure the
"name" entry remains and adjust descriptions to reflect matching patterns and
optionality.
- Around line 26-30: In _silence.mdx update the templateEnv entries so their
"url" values include the /docs prefix (i.e., change
"/reference/notifications/template_vars/checks",
"/reference/notifications/template_vars/config", and
"/reference/notifications/template_vars/components" to
"/docs/reference/notifications/template_vars/checks",
"/docs/reference/notifications/template_vars/config", and
"/docs/reference/notifications/template_vars/components"); locate the
templateEnv array in _silence.mdx and edit the three URL strings so they match
the /docs/... path used elsewhere.
🧹 Nitpick comments (2)
mission-control/docs/guide/notifications/concepts/silences.mdx (2)
30-37: Consider adding a full CR example with a filter.Per reviewer feedback, a full
NotificationSilencespec example that includes afilterfield would help users understand how to combine selectors and filters in practice. The YAML fixture imported on line 21 may partially cover this — verify it includes a filter example, and if not, consider adding a second fixture import that demonstrates one.
56-61: Long CEL expression in table cell may hurt readability.The
catalog.traverse(...)filter on line 61 is very long for a markdown table cell. Consider moving complex examples into a separate code block below the table, or breaking the expression across multiple lines with explanation.
adityathebe
force-pushed
the
docs/silences-crd
branch
from
d5edf89 to
8c5552b
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (4)
mission-control/docs/reference/notifications/_env_vars.mdx (1)
48-90: Consider extracting shared fields to reduce duplication.
silenceURL,channel, andgroupedResourcesare defined identically in bothCheckHealthEnvandConfigEventsTemplateVars. You could extract these into a shared array and spread them into bothrowsarrays to keep them in sync.This is a minor nit for a docs file — fine to defer.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@mission-control/docs/reference/notifications/_env_vars.mdx` around lines 48 - 90, ConfigEventsTemplateVars duplicates fields (silenceURL, channel, groupedResources) that are also present in CheckHealthEnv; extract those three field objects into a shared constant (e.g., SHARED_NOTIFICATION_FIELDS) and then spread that array into the rows arrays in both ConfigEventsTemplateVars and CheckHealthEnv so both functions reference the single source of truth for those fields.mission-control/docs/guide/notifications/concepts/silences.mdx (3)
59-66: Long filter expression in line 66 will render poorly in the table.The
catalog.traverse(...)filter expression is ~200 characters wide and will cause horizontal overflow in the rendered table. Consider moving it below the table as a standalone fenced code block with an explanation, or splitting it across multiple lines using a code block within the cell.📝 One approach: extract complex example below the table
Replace line 66 in the table with a simpler entry, then add the complex example as a standalone block after the table:
-| `config.type == "Kubernetes::Pod" && catalog.traverse(config.id, "Kubernetes::Namespace", "incoming").size > 0 && catalog.traverse(config.id, "Kubernetes::Namespace", "incoming")[0].tags.?env.orValue("") == "prod"` | Matches pods in production namespaces | +| See advanced example below | Matches pods in production namespaces |Then after the table:
**Advanced filter example — Matching pods in production namespaces:** ```cel config.type == "Kubernetes::Pod" && catalog.traverse(config.id, "Kubernetes::Namespace", "incoming").size > 0 && catalog.traverse(config.id, "Kubernetes::Namespace", "incoming")[0].tags.?env.orValue("") == "prod" `` `🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@mission-control/docs/guide/notifications/concepts/silences.mdx` around lines 59 - 66, The long catalog.traverse(...) filter expression causes horizontal overflow in the table; replace that table cell's complex entry with a short summary (e.g., "Matches pods in production namespaces") and move the full expression out of the table into a fenced code block below with a brief heading, then format the expression across multiple lines using logical operators (referencing the exact expression using catalog.traverse(config.id, "Kubernetes::Namespace", "incoming"), .size, [0].tags.?env.orValue("") and config.type == "Kubernetes::Pod") so readers get the full advanced example without breaking the table layout.
47-49: Consider clarifying the filter/selector relationship as "OR" logic.The current wording accurately describes the evaluation order, but readers may not immediately grasp that this is effectively an OR — a silence triggers if either the filter or a selector matches. Adding a brief "i.e., the silence applies if either the filter or a selector matches" would make the intent immediately obvious.
📝 Suggested wording
-When both `filter` and `selectors` are specified, the filter is evaluated first. If the filter matches, the silence is applied. Selectors are only evaluated if the filter does not match. +When both `filter` and `selectors` are specified, either one can trigger the silence (OR logic). The filter is evaluated first — if it matches, the silence is applied immediately. Selectors are only evaluated if the filter does not match.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@mission-control/docs/guide/notifications/concepts/silences.mdx` around lines 47 - 49, The info admonition that currently explains evaluation order for `filter` and `selectors` should explicitly state the logical relationship as OR: update the text inside the info block so it ends with a short clarifying sentence such as "i.e., the silence applies if either the `filter` matches or any `selector` matches" to make the intent immediate while keeping the existing evaluation-order detail; touch the line containing the `When both `filter` and `selectors` are specified...` paragraph and append the OR clarification referencing `filter` and `selectors`.
51-53: Selectors section could be more detailed per reviewer feedback.moshloop noted the selectors table appears incomplete. Currently this section only links to the Resource Selectors reference page without showing the available selector fields (e.g.,
types,names,namespaces,labels,tags). Consider adding a brief table or inline summary of the key selector fields to make this section self-contained, similar to how the Filters section provides inline examples.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@mission-control/docs/guide/notifications/concepts/silences.mdx` around lines 51 - 53, Update the "Selectors" section to include a concise inline summary of the available selector fields (instead of only linking to Resource Selectors): list the key fields `types`, `names`, `namespaces`, `labels`, and `tags`, describe expected value formats (e.g., `types: ["Pod","Deployment"]`, `names: ["web-1"]`, `namespaces: ["prod"]`, `labels: {"app":"frontend"}` or label selectors, `tags: ["critical"]`), and add one short example showing multiple selectors combined; keep the reference link to /docs/reference/resource-selector for full details.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@mission-control/docs/guide/notifications/concepts/silences.mdx`:
- Around line 20-22: The fenced code block uses an empty title and a
likely-nonexistent fixture path and has a trailing space; update the
triple-backtick block attributes by either replacing title="" with a meaningful
title (e.g., title="silence test env") or removing the title attribute, correct
or remove the file attribute if
<rootDir>/modules/mission-control/fixtures/silences/silence-test-env.yaml does
not exist (or point it to the actual fixture path), and remove the trailing
space at the end of the block so the code fence is clean; look for the code
block that contains the attributes "title" and
"file=<rootDir>/modules/mission-control/fixtures/silences/silence-test-env.yaml"
to apply these changes.
---
Nitpick comments:
In `@mission-control/docs/guide/notifications/concepts/silences.mdx`:
- Around line 59-66: The long catalog.traverse(...) filter expression causes
horizontal overflow in the table; replace that table cell's complex entry with a
short summary (e.g., "Matches pods in production namespaces") and move the full
expression out of the table into a fenced code block below with a brief heading,
then format the expression across multiple lines using logical operators
(referencing the exact expression using catalog.traverse(config.id,
"Kubernetes::Namespace", "incoming"), .size, [0].tags.?env.orValue("") and
config.type == "Kubernetes::Pod") so readers get the full advanced example
without breaking the table layout.
- Around line 47-49: The info admonition that currently explains evaluation
order for `filter` and `selectors` should explicitly state the logical
relationship as OR: update the text inside the info block so it ends with a
short clarifying sentence such as "i.e., the silence applies if either the
`filter` matches or any `selector` matches" to make the intent immediate while
keeping the existing evaluation-order detail; touch the line containing the
`When both `filter` and `selectors` are specified...` paragraph and append the
OR clarification referencing `filter` and `selectors`.
- Around line 51-53: Update the "Selectors" section to include a concise inline
summary of the available selector fields (instead of only linking to Resource
Selectors): list the key fields `types`, `names`, `namespaces`, `labels`, and
`tags`, describe expected value formats (e.g., `types: ["Pod","Deployment"]`,
`names: ["web-1"]`, `namespaces: ["prod"]`, `labels: {"app":"frontend"}` or
label selectors, `tags: ["critical"]`), and add one short example showing
multiple selectors combined; keep the reference link to
/docs/reference/resource-selector for full details.
In `@mission-control/docs/reference/notifications/_env_vars.mdx`:
- Around line 48-90: ConfigEventsTemplateVars duplicates fields (silenceURL,
channel, groupedResources) that are also present in CheckHealthEnv; extract
those three field objects into a shared constant (e.g.,
SHARED_NOTIFICATION_FIELDS) and then spread that array into the rows arrays in
both ConfigEventsTemplateVars and CheckHealthEnv so both functions reference the
single source of truth for those fields.
Add silenceURL, channel, recent_events, and groupedResources to check and config event template variable docs. Fix templateEnv URLs in silence reference to use /docs/ prefix.
adityathebe
force-pushed
the
docs/silences-crd
branch
from
8c5552b to
4cadec2
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
mission-control/docs/guide/notifications/concepts/silences.mdx (1)
61-66: Long filter expression in Line 66 hurts table readability.The
catalog.traversefilter example on Line 66 is very long and will likely overflow horizontally in the rendered table. Consider moving complex examples into a dedicated code block below the table with an explanation, keeping only concise examples in the table.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@mission-control/docs/guide/notifications/concepts/silences.mdx` around lines 61 - 66, The table row containing the long filter using catalog.traverse (the expression starting with config.type == "Kubernetes::Pod" && catalog.traverse(...)) should be shortened to keep the table readable: replace the long expression in the table with a concise example or a short placeholder like "See example below" and move the full complex filter into a separate code block immediately below the table with a brief explanation of what it matches; update any nearby text to reference the code block and ensure the complex filter uses the same symbols (catalog.traverse, config.id, Kubernetes::Namespace, tags.?env.orValue("")) so readers can correlate the example with the table entry.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@mission-control/docs/guide/notifications/concepts/silences.mdx`:
- Around line 20-22: The code block reference to a fixture is broken: update the
YAML code block metadata so the file path points to an existing fixture and
provide a non-empty title; specifically edit the fenced code block that
currently lists
file=<rootDir>/modules/mission-control/fixtures/silences/silence-test-env.yaml
and title="" to either correct the file path to the actual fixture (or remove
the file attribute if none) and set a meaningful title (e.g., title="silence
test env") so the markdown includes a valid fixture reference.
---
Nitpick comments:
In `@mission-control/docs/guide/notifications/concepts/silences.mdx`:
- Around line 61-66: The table row containing the long filter using
catalog.traverse (the expression starting with config.type == "Kubernetes::Pod"
&& catalog.traverse(...)) should be shortened to keep the table readable:
replace the long expression in the table with a concise example or a short
placeholder like "See example below" and move the full complex filter into a
separate code block immediately below the table with a brief explanation of what
it matches; update any nearby text to reference the code block and ensure the
complex filter uses the same symbols (catalog.traverse, config.id,
Kubernetes::Namespace, tags.?env.orValue("")) so readers can correlate the
example with the table entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
resolves: #389
Summary by CodeRabbit
Release Notes