Improve views docs #444
Improve views docs #444
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughRestructured Mission Control views documentation from monolithic concept files into granular per-type documentation pages. Added templating variables guide. Updated view schema reference to document new panel types, query sources, and column types. Updated submodule pointers across multiple modules. Applied formatting corrections throughout documentation. Changes
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ 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 |
adityathebe
force-pushed
the
docs/views
branch
from
654704a to
2132fbd
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
mission-control/docs/guide/config-db/concepts/relationships.md (1)
8-8: Fix typo in tip header."Integarations" should be "Integrations."
-:::tip Integarations +:::tip Integrationsmission-control/docs/guide/config-db/scrapers/azure.md (1)
56-58: Fix malformed table structure.Line 57 contains an extra column separator that creates a malformed table with 3 columns instead of 2. This will break table rendering.
| Resource Type | Config Class | -| ------------------------------------------ | --------------------- | --- | +| ------------------------------------------ | --------------------- |Verify the entire Resource Types table renders correctly after this fix.
mission-control/docs/reference/playbooks/events.md (1)
45-64: CRITICAL: Corrupted YAML example paths in playbook definition.The playbook name and filter contain malformed paths that mix documentation file paths with YAML field values:
- Line 45: Filename contains
/docs/guide/canary-checker/reference/database-component.yaml- Line 49: Playbook name contains
/docs/guide/canary-checker/reference/database- Line 51: Description contains
/docs/guide/canary-checker/reference/database- Line 55:
component.typefilter contains/docs/guide/canary-checker/reference/databaseThese paths appear to be corrupted—
component.typeshould be a feature identifier (e.g.,"database"), not a documentation path. Similarly, the playbook name and filename should not contain doc paths.Please clarify the intended values for this example. Likely corrections:
- name: notify-unhealthy-/docs/guide/canary-checker/reference/database-component + name: notify-unhealthy-database-component- description: Notify when a /docs/guide/canary-checker/reference/database component goes unhealthy + description: Notify when a database component goes unhealthy- filter: component.type == '/docs/guide/canary-checker/reference/database' + filter: component.type == 'database'
🧹 Nitpick comments (8)
mission-control/docs/guide/views/concepts/cache-control.md (2)
214-225: Clarify Performance Impact table column headers.The column headers with "↓" symbols are ambiguous—it's unclear whether they indicate "reduces/improves" or show some other metric. Readers may misinterpret the ✓/✗ symbols without explicit context.
Consider adding a legend or rephrasing the headers to be more explicit:
-| Setting | ↓ Latency | ↓ Load | ↓ Freshness | +| Setting | Latency Impact | Load Impact | Freshness Impact | -| ---------------------- | --------- | ------ | ----------- | -| Shorter maxAge | ✗ | ✗ | ✓ | -| Longer maxAge | ✓ | ✓ | ✗ | -| Shorter refreshTimeout | ✓ | ✗ | ✗ | -| Longer refreshTimeout | ✗ | ✓ | ✓ | -| Higher minAge | ✓ | ✓ | ✗ | -| Lower minAge | ✗ | ✗ | ✓ | +| Shorter maxAge | Worsens | Worsens | Improves | +| Longer maxAge | Improves | Improves | Worsens | +| Shorter refreshTimeout | Improves | Worsens | Worsens | +| Longer refreshTimeout | Worsens | Improves | Improves | +| Higher minAge | Improves | Improves | Worsens | +| Lower minAge | Worsens | Worsens | Improves |Alternatively, add a note above the table explaining the symbols: "✓ = beneficial for this metric, ✗ = detrimental."
214-225: Clarify Performance Impact table column headers.The column headers using "↓" symbols are ambiguous—readers may misinterpret whether they indicate "reduces," "impacts," or something else. The ✓/✗ semantics would be clearer with explicit context.
Consider rephrasing for clarity:
-| Setting | ↓ Latency | ↓ Load | ↓ Freshness | +| Setting | Latency | Load | Freshness | -| ---------------------- | --------- | ------ | ----------- | -| Shorter maxAge | ✗ | ✗ | ✓ | -| Longer maxAge | ✓ | ✓ | ✗ | -| Shorter refreshTimeout | ✓ | ✗ | ✗ | -| Longer refreshTimeout | ✗ | ✓ | ✓ | -| Higher minAge | ✓ | ✓ | ✗ | -| Lower minAge | ✗ | ✗ | ✓ | +| Shorter maxAge | Worsens | Worsens | Improves | +| Longer maxAge | Improves | Improves | Worsens | +| Shorter refreshTimeout | Improves | Worsens | Worsens | +| Longer refreshTimeout | Worsens | Improves | Improves | +| Higher minAge | Improves | Improves | Worsens | +| Lower minAge | Worsens | Worsens | Improves |Alternatively, add a legend: "(✓ = improves metric, ✗ = worsens metric)".
mission-control/docs/guide/views/table/index.md (2)
13-15: Vary sentence structure in "When to Use" section.Three successive list items begin with "You," creating repetitive structure. Consider rewording to add variety:
## When to Use -- You need sortable, filterable rows for configs, changes, or metrics. -- You want to mix multiple data sources into one grid via SQL `merge`. -- You want card layouts (titles, subtitles, gauges) backed by the same table data. +- Display sortable, filterable rows for configs, changes, or metrics. +- Mix multiple data sources into one grid via SQL `merge`. +- Present card layouts (titles, subtitles, gauges) backed by the same table data.
1-47: Approve comprehensive Table view documentation.The page provides clear anatomy, usage scenarios, best practices, and examples. The structure effectively guides users through table design decisions. Once fixture files are verified and sentence structure is refined, this addition aligns well with the PR objectives.
prompts/style.md (1)
1-62: Approve expanded writing style guidelines.The additions clarify MDX formatting requirements and expand the inclusive language section with concrete, actionable examples. The guidelines are comprehensive and well-organized. Once the typo is fixed, these updates will strengthen documentation consistency across the project.
mission-control/docs/guide/views/concepts/templating.md (1)
448-465: SQL injection risk deserves stronger documentation.Line 466 briefly mentions parameterized queries for user input handling, but this critical security concern is buried at the end and could be overlooked. Consider promoting this to a dedicated callout box (e.g.,
:::warning) that explains the risk explicitly: string substitution happens before query execution, so malicious values in$(var.key)could inject SQL. Suggest input validation, allowlisting, or parameterized queries as mitigation.Example warning box:
:::warning Security: Dynamic SQL with Variables String substitution of `$(var.key)` occurs before query execution. If variable values come from untrusted sources, this can expose SQL injection risks. Mitigation strategies: - Validate/allowlist variable values server-side - Use parameterized queries where possible - Restrict dynamic variables to system-provided values (e.g., config item names) :::mission-control/docs/reference/views/_view.mdx (1)
407-427: Clarify timeseries implementation status.Line 409 notes "(API-level; UI rendering in progress)". This suggests the feature may not be fully stable. Consider explicitly stating:
- Is this API usable now but UI rendering incomplete?
- Should users avoid timeseries until UI is ready?
- Will there be a breaking change once UI rendering lands?
This helps users understand support status.
mission-control/docs/guide/views/panels/table.md (1)
7-7: Refine terminology for clarity.The phrase "key-value list" may be ambiguous to readers. Consider stating more explicitly what the visual layout is: "displays query results in a two-column format with labels on the left and values on the right" or similar, to set clear expectations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
mission-control/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (60)
mission-control-chart(1 hunks)mission-control/blog/state-based-alerting/index.md(11 hunks)mission-control/docs/guide/config-db/concepts/relationships.md(1 hunks)mission-control/docs/guide/config-db/concepts/retention.md(2 hunks)mission-control/docs/guide/config-db/concepts/transform.md(3 hunks)mission-control/docs/guide/config-db/scrapers/azure.md(1 hunks)mission-control/docs/guide/playbooks/_api.md(2 hunks)mission-control/docs/guide/playbooks/actions/index.md(2 hunks)mission-control/docs/guide/views/concepts/cache-control.md(2 hunks)mission-control/docs/guide/views/concepts/panels.md(0 hunks)mission-control/docs/guide/views/concepts/queries.md(0 hunks)mission-control/docs/guide/views/concepts/tables.md(0 hunks)mission-control/docs/guide/views/concepts/templating.md(1 hunks)mission-control/docs/guide/views/index.md(3 hunks)mission-control/docs/guide/views/panels/bargauge.md(1 hunks)mission-control/docs/guide/views/panels/duration.md(1 hunks)mission-control/docs/guide/views/panels/gauge.md(1 hunks)mission-control/docs/guide/views/panels/index.mdx(1 hunks)mission-control/docs/guide/views/panels/number.md(1 hunks)mission-control/docs/guide/views/panels/piechart.md(1 hunks)mission-control/docs/guide/views/panels/table.md(1 hunks)mission-control/docs/guide/views/panels/text.md(1 hunks)mission-control/docs/guide/views/queries/changes.md(1 hunks)mission-control/docs/guide/views/queries/configs.md(1 hunks)mission-control/docs/guide/views/queries/index.mdx(1 hunks)mission-control/docs/guide/views/queries/prometheus.md(1 hunks)mission-control/docs/guide/views/queries/sql.md(1 hunks)mission-control/docs/guide/views/queries/view-table-selector.md(1 hunks)mission-control/docs/guide/views/table/columns/badge.md(1 hunks)mission-control/docs/guide/views/table/columns/boolean.md(1 hunks)mission-control/docs/guide/views/table/columns/bytes.md(1 hunks)mission-control/docs/guide/views/table/columns/config-item.md(1 hunks)mission-control/docs/guide/views/table/columns/datetime.md(1 hunks)mission-control/docs/guide/views/table/columns/duration.md(1 hunks)mission-control/docs/guide/views/table/columns/gauge.md(1 hunks)mission-control/docs/guide/views/table/columns/health.md(1 hunks)mission-control/docs/guide/views/table/columns/index.mdx(1 hunks)mission-control/docs/guide/views/table/columns/labels.md(1 hunks)mission-control/docs/guide/views/table/columns/millicore.md(1 hunks)mission-control/docs/guide/views/table/columns/number.md(1 hunks)mission-control/docs/guide/views/table/columns/status.md(1 hunks)mission-control/docs/guide/views/table/columns/string.md(1 hunks)mission-control/docs/guide/views/table/index.md(1 hunks)mission-control/docs/integrations/flux/catalog.md(0 hunks)mission-control/docs/reference/canary-checker/check.md(1 hunks)mission-control/docs/reference/config-db/properties.md(1 hunks)mission-control/docs/reference/config-db/scrape-result.md(1 hunks)mission-control/docs/reference/playbooks/events.md(1 hunks)mission-control/docs/reference/playbooks/index.md(2 hunks)mission-control/docs/reference/resource-selector.md(0 hunks)mission-control/docs/reference/views/_view.mdx(11 hunks)modules/canary-checker(1 hunks)modules/config-db(1 hunks)modules/duty(1 hunks)modules/mission-control(1 hunks)modules/mission-control-chart(1 hunks)modules/mission-control-registry(1 hunks)prompts/blog.md(3 hunks)prompts/style.md(2 hunks)scripts/README.md(1 hunks)
💤 Files with no reviewable changes (5)
- mission-control/docs/reference/resource-selector.md
- mission-control/docs/guide/views/concepts/queries.md
- mission-control/docs/integrations/flux/catalog.md
- mission-control/docs/guide/views/concepts/panels.md
- mission-control/docs/guide/views/concepts/tables.md
🧰 Additional context used
🪛 LanguageTool
prompts/blog.md
[grammar] ~19-~19: Use a hyphen to join words.
Context: ...vices, nodes, PVC, ingress, etc.. State based alerting (i.e. whene resource self...
(QB_NEW_EN_HYPHEN)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...books that can then proactively collect infomation in a distrubuted fashion from agents de...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...hen proactively collect infomation in a distrubuted fashion from agents deployed closest to...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ... into the model which tan the recommend futher playbooks to execute. This is advantag...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~38-~38: Use a hyphen to join words.
Context: ...ontext and initial challenges. - Step by step guide - Common Pitfalls - Hig...
(QB_NEW_EN_HYPHEN)
[grammar] ~38-~38: Use a hyphen to join words.
Context: ...ext and initial challenges. - Step by step guide - Common Pitfalls - Highli...
(QB_NEW_EN_HYPHEN)
mission-control/docs/guide/views/table/index.md
[style] ~15-~15: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ources into one grid via SQL merge. - You want card layouts (titles, subtitles, g...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
mission-control/blog/state-based-alerting/index.md
[grammar] ~9-~9: Ensure spelling is correct
Context: ...tion vs Infrastructure Application and infrastucture normally have very different failure sc...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...(that produce exceptions) or performance related problems. When there are problem...
(QB_NEW_EN_HYPHEN)
[grammar] ~9-~9: Ensure spelling is correct
Context: ...ems. When there are problems it becomes immiedatly obvious - page fails to load or starts ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~11-~11: Use a hyphen to join words.
Context: ...hat primarily use metrics (and log/trace derived metrics) that define thresholds ...
(QB_NEW_EN_HYPHEN)
[grammar] ~11-~11: Ensure spelling is correct
Context: ...s for known health states. It is fairly straightforard to define healthy, unhealthy and warnin...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~11-~11: Ensure spelling is correct
Context: ...hy, unhealthy and warning states. These methodoligies struggle with unknown states i.e. we ar...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~15-~15: Use a hyphen to join words.
Context: ...ric (Thresholds and Anomalies) ## State Based ## Synthetic Testing Infrastruct...
(QB_NEW_EN_HYPHEN)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...Infrastructure errors tend be more state oreinted ## Alerting Types and Examples There are v...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~219-~219: Ensure spelling is correct
Context: ...conciled. This is example isn't really thay useful, as it needs to be run continous...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
mission-control/docs/reference/playbooks/index.md
[style] ~10-~10: Consider using the synonym “brief” (= concise, using a few words, not lasting long) to strengthen your wording.
Context: ...------------- | | description | A short description ...
(QUICK_BRIEF)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | | | github | Trigger Github Action ...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | | github | Trigger Github Action ...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | [Github Action](/docs/guide/playbooks/actions/g...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | Github Action ...
(GITHUB)
mission-control/docs/guide/config-db/concepts/relationships.md
[grammar] ~65-~65: Ensure spelling is correct
Context: ... | | ### Lookup RelationshipLookup offers different ways...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
mission-control/docs/guide/playbooks/_api.md
[style] ~134-~134: Consider using “who” when you are referring to a person instead of an object.
Context: ...string | The ID of the user that created the run. | |conf...
(THAT_WHO)
🔇 Additional comments (75)
mission-control/docs/guide/playbooks/actions/index.md (1)
10-24: Table formatting improvements look good.The reflowing and consistent line-wrapping across both tables (Actions fields and Context variables) improve readability and align with documentation standards.
Also applies to: 80-86
mission-control/docs/guide/playbooks/_api.md (1)
58-61: Table formatting improvements look good.The Query Parameters (lines 58-61) and GET /playbook/run/{id} Response (lines 126-137) tables have been reformatted for better alignment and readability without changing semantic content.
Also applies to: 126-137
mission-control/docs/guide/views/concepts/cache-control.md (6)
156-166: Minor: Improve formatting consistency in Example 4.The last cache behavior example ends differently from the others. It lacks a clear final result line (e.g., "User must wait..." is present, but the scenario doesn't show an outcome like "Request rejected" or similar). Consider adding a closing line for consistency:
User clicks refresh button ↓ Check minAge: Last refresh was 2 seconds ago, minAge=10s ↓ Too soon → Ignore refresh request ↓ User must wait 8 more seconds before refresh is allowed + ↓ +Request rejected
7-238: Approve documentation structure and content.The restructured documentation is well-organized, practical, and comprehensive. The progression from overview through parameters to examples and recommendations is logical and helps readers understand both the concepts and practical application. Default values are consistent throughout, and the preset configurations provide useful guidance for different use cases.
156-166: Minor formatting inconsistency in Example 4.The final example ends abruptly without a concluding result line. Examples 1–3 show a final outcome (e.g., "Response time: ~10ms"); Example 4 trails off with "User must wait 8 more seconds."
Consider adding:
User clicks refresh button ↓ Check minAge: Last refresh was 2 seconds ago, minAge=10s ↓ Too soon → Ignore refresh request ↓ User must wait 8 more seconds before refresh is allowed + ↓ +Refresh request rejected and throttled
7-238: Approve documentation structure and content.The restructured documentation is well-organized and practical. The progression from overview through parameters, examples, and presets is logical and user-friendly. Default values are consistent throughout, and the four preset configurations (High-Frequency, Typical, Low-Frequency, Real-Time Critical) provide actionable guidance. The Per-Variable Caching and Cache Behavior Examples sections effectively illustrate real-world scenarios.
1-5: Verify icon identifier validity in documentation system and cache behavior documentation accuracy.The
mdi:cachedicon identifier is valid within the Material Design Icons ecosystem and uses the standard "mdi:" namespace prefix supported by Iconify and other icon tools. However, verify that your documentation system explicitly supports this icon namespace (confirm with system documentation or test the build).Additionally, ensure the caching behavior, defaults, and examples described in this document match the actual implementation in the codebase—this could not be verified due to repository access limitations.
1-5: Icon identifiermdi:cachedis valid and supported.The icon is confirmed as a valid identifier in the Material Design Icons (MDI) library and is supported by Iconify and Home Assistant systems using the format "mdi:cached".
However, verification of whether the caching behavior, defaults, and examples in the documentation match the actual codebase implementation could not be completed due to repository access limitations. Manual review of the cache-control guide content against the actual implementation is recommended before merging.
modules/mission-control-chart (1)
1-1: Verify the submodule commit update before merging.The submodule pointer has been updated to
2a91080def4f14679f38331c6b0fe05f610380cd. Ensure this commit exists in the mission-control-chart repository and contains the intended documentation changes referenced in this PR.modules/duty (1)
1-1: Verify submodule commit hash and clarify the rationale for this update.The submodule pointer is being updated to a new commit hash. Please confirm:
- The new commit hash exists and is accessible in the duty module repository
- The rationale for updating this submodule in the context of the views documentation improvements (PR objective #438)
- Whether this update is intentional or should be rolled back to align with the PR scope
The AI summary indicates this is part of coordinated submodule updates across multiple modules (mission-control-chart, config-db, mission-control, canary-checker). Please verify that all related updates are necessary and compatible with the views documentation restructuring.
mission-control-chart (1)
1-1: Verify that the submodule update is intentional and related to PR objectives.This change updates the
mission-control-chartsubmodule commit pointer, but the PR objectives focus on restructuring views documentation. Please clarify whether this submodule bump is:
- A necessary dependency update for the documentation changes
- An intentional inclusion that should be documented in the PR description
- Unrelated and should be removed from this PR
Provide context on what changed in the submodule and why it's required for this PR.
modules/canary-checker (1)
1-1: Clarify the rationale for the submodule update in a documentation PR.This change updates the
canary-checkersubmodule pointer, which appears orthogonal to the stated PR objectives of restructuring Mission Control views documentation. The AI summary indicates this is part of broader submodule pointer updates across multiple modules.Please clarify:
- Is this submodule update intentional as part of this PR, or was it included accidentally?
- Are there dependencies in the canary-checker module that are required for the documentation changes?
- If intentional, consider whether it should be split into a separate PR for clearer change tracking and review.
modules/config-db (1)
1-1: Clarify the purpose of the config-db submodule pointer update.This file updates a git submodule commit reference (218a9c93... → f26106b24...), but its relationship to the views documentation improvements (PR #438 objectives) is unclear. Submodule updates should be accompanied by an explanation of why they are necessary and how they support the stated PR goals.
Verify:
- Is this submodule update intentional and necessary for the PR objectives?
- What changes are included in this submodule commit?
- Was this update included intentionally or as part of a broader dependency sync?
mission-control/docs/reference/canary-checker/check.md (1)
5-26: Table formatting improvements look good.The reference table restructuring maintains all field definitions while improving column alignment and readability. No semantic changes detected.
mission-control/docs/guide/views/table/columns/bytes.md (2)
1-18: Documentation structure and content are solid.The bytes column type documentation follows the established pattern, clearly explains auto-formatting behavior with concrete examples, and integrates well with the broader column type documentation initiative.
19-20: Verify the external file reference exists at the specified location.The example references
modules/mission-control/fixtures/views/pods.yamlat lines 41-44. Ensure this file exists and contains a valid bytes column example at the indicated line range.mission-control/docs/guide/views/table/columns/health.md (2)
1-15: Health column documentation is concise and well-structured.The documentation clearly explains the three health states with color coding. The usage note about
card.useForAccent: trueadds practical value. Consider whether a state-decision table or additional usage guidance (e.g., how to determine when to use warning vs. unhealthy) would enhance clarity, but the current content aligns well with the PR objectives for per-type column documentation.
11-12: Verify external file reference for health column example.The example references
modules/mission-control/fixtures/views/ingress.yamlat lines 41-47. Confirm this file exists and contains a valid health column example at the specified range.scripts/README.md (1)
53-53: Trailing newline formatting adjustment.Minor file-ending formatting adjustment. No content changes detected.
modules/mission-control (1)
1-1: Verify the submodule pointer update and alignment with documentation changes.The submodule commit reference has been updated. Since the actual changes in the upstream commit are not visible in this diff, please verify:
- The commit
b76b2b284613bc987064cc8d2e3eba0f4a2ba8abis valid and intentional.- Any schema, API, or structural changes in the upstream commit align with the documentation restructuring in this PR (especially the views documentation overhaul from issue #438).
- Whether similar updates across
mission-control-chart,canary-checker,config-db,duty, andmission-control-registryare coordinated and necessary.mission-control/docs/guide/views/table/columns/number.md (1)
16-19: Verify the fixture file example is rendering correctly.The example code block appears to be empty. Verify that the fixture file reference
<rootDir>/modules/mission-control/fixtures/views/notification-send-history.yamlexists and that lines 27-30 are valid. If the documentation framework requires these examples to be populated, confirm the file path and line numbers are correct.mission-control/docs/guide/views/table/columns/badge.md (1)
9-12: Verify the fixture file example is rendering correctly.The example code block appears to be empty. Verify that the fixture file reference
<rootDir>/modules/mission-control/fixtures/views/backups.yamlexists and that lines 30-32 are valid. If the documentation framework requires these examples to be populated, confirm the file path and line numbers are correct.mission-control/docs/reference/config-db/scrape-result.md (1)
6-23: Formatting changes improve table readability.The table formatting and spacing adjustments enhance visual clarity without affecting content or functionality.
modules/mission-control-registry (1)
1-1: Verify the necessity and safety of the submodule update.The submodule pointer has been updated to a new commit. Since this PR is focused on documentation improvements, please confirm:
- Whether this update is intentional and necessary for the documentation changes.
- Whether the referenced commit introduces any breaking changes or significant behavioral shifts.
- Why this particular commit was selected (ideally documented in the PR description or commit message).
Generally, submodule updates in documentation-focused PRs warrant explicit rationale to ensure they are deliberate rather than accidental dependency shifts.
mission-control/docs/guide/views/table/columns/config-item.md (1)
11-15: Incomplete example code block.The example section references a fixture file but the code block is empty. Verify whether this is intentional (content populated at build time) or if the YAML example needs to be filled in.
mission-control/docs/reference/config-db/properties.md (1)
6-32: Table formatting alignment is consistent.The formatting updates to both tables maintain alignment and readability. No semantic changes detected.
prompts/blog.md (1)
47-49: Instruction improvements are clear and helpful.The added details for command documentation (explain before, details after) and file documentation (introduce purpose, then explain changes) enhance clarity for technical writers following this prompt.
mission-control/docs/guide/views/table/columns/status.md (1)
9-13: Incomplete example code block.The example section references a fixture file but the code block is empty. Verify whether this is intentional (content populated at build time) or if the YAML example needs to be filled in.
mission-control/docs/guide/views/table/columns/duration.md (1)
9-13: Incomplete example code block.The example section references a fixture file but the code block is empty. Verify whether this is intentional (content populated at build time) or if the YAML example needs to be filled in.
mission-control/docs/guide/views/table/columns/string.md (1)
9-13: Incomplete example code block.The example section references a fixture file but the code block is empty. Verify whether this is intentional (content populated at build time) or if the YAML example needs to be filled in.
mission-control/docs/guide/views/table/columns/boolean.md (2)
9-13: Incomplete example code block.The example section references a fixture file but the code block is empty. Verify whether this is intentional (content populated at build time) or if the YAML example needs to be filled in.
15-15: Helpful feature documentation.The note about
filter.type: multiselectand its optimization benefit (avoiding view refresh) adds practical value for users implementing boolean filters.mission-control/docs/guide/config-db/concepts/transform.md (1)
14-21: Consistent table formatting throughout.All table formatting updates maintain alignment and readability across the transformation concepts. No semantic changes to field definitions, descriptions, or requirements.
Also applies to: 79-83, 141-146, 152-154
mission-control/docs/guide/config-db/concepts/relationships.md (1)
56-80: Approve formatting updates to table structure.The table header and separator reformatting is consistent with documentation best practices. No semantic changes detected.
mission-control/docs/guide/config-db/concepts/retention.md (1)
12-25: Approve table formatting updates.The reformatting of table headers and column separators is purely a presentation refinement. No semantic changes detected.
mission-control/docs/guide/views/table/columns/datetime.md (2)
1-13: Approve new DateTime column documentation.The new documentation page follows established patterns for column type documentation. Assuming the fixture file reference is valid, this addition aligns well with the PR objectives to provide per-column-type documentation.
11-11: Verify fixture file reference.The fixture file reference at
modules/mission-control/fixtures/views/cronjobs.yamllines 32-33 could not be verified due to environment limitations. Ensure this file exists and contains the expected datetime column configuration at the specified lines.mission-control/docs/guide/views/table/columns/labels.md (2)
1-19: Approve new Labels column documentation with helpful behavior guidance.The documentation page provides clear, actionable information about the labels column type, including JSON object requirements and multiselect filtering behavior. The UI encoding guidance adds practical value for users. Assuming fixture file reference is valid, this addition aligns well with documentation goals.
11-11: Verify fixture file reference.Ensure the fixture file
modules/mission-control/fixtures/views/pods.yamlexists and contains content at lines 49-50 as referenced in the code block.mission-control/docs/guide/config-db/scrapers/azure.md (1)
20-40: Approve Scraper and Azure config table formatting.The table formatting for Scraper and Azure configuration fields is properly structured and aligns with documentation standards.
mission-control/docs/guide/views/queries/index.mdx (1)
1-11: Approve new Queries index page with DocCardList component.The DocCardList component automatically infers items from the parent sidebar category when the items prop is optional, so this usage is valid. The file structure correctly sets up an index page for the queries documentation section. This addition aligns with the PR's documentation reorganization objectives.
mission-control/docs/guide/views/table/index.md (1)
29-29: Verify fixture file references.Ensure the fixture files and line ranges exist as referenced in code blocks. The file
modules/mission-control/fixtures/views/namespace.yamland its specified line ranges (7-66) need to be verified to exist with the expected content.Also applies to: 37-37
mission-control/docs/guide/views/panels/piechart.md (2)
1-20: Content is clear and well-structured.The table panel documentation accurately describes the simple key-value display format with clear expectations for column structure. Example reference is appropriate.
Verify that
table.yamlfixture exists and contains a working example with the expected columns (value and label).
27-30: Verify fixture file exists and contains expected example.The example references
piechart.yamlfixture file atmodules/mission-control/fixtures/views/panels/piechart.yaml. Ensure this file exists and demonstrates a working piechart configuration with the properties and columns documented above.mission-control/docs/guide/views/panels/text.md (1)
1-18: Well-documented use case with clear expectations.The text panel documentation clearly explains its purpose and provides helpful context for when to use it. The expected columns section correctly identifies the single required column.
Verify that
text.yamlfixture exists and demonstrates text panel usage.mission-control/docs/guide/views/queries/view-table-selector.md (1)
1-39: Excellent documentation with practical guidance.This query type documentation is comprehensive and well-organized. The overview clearly explains the purpose, the tips section provides actionable guidance (especially on inheriting column types and using labelSelector for composition), and the example demonstrates a real use case with aggregation.
Verify that the
deployments-summary.yamlfixture exists and that lines 10-37 contain a working example with View Table Selector configuration.mission-control/docs/guide/views/table/columns/millicore.md (1)
1-20: Clear explanation of millicore unit with helpful conversion reference.The conversion table effectively illustrates the millicore-to-core relationship and display format, making it easy for users to understand the scale. The specific line range reference in the example is appropriate.
Verify that
pods.yamlfixture exists and that lines 45-48 contain a millicore column example.mission-control/docs/guide/views/panels/duration.md (1)
1-20: Well-specified with clear unit documentation.The duration panel documentation clearly specifies the nanosecond input unit and provides helpful output format examples. The optional label column is appropriately documented.
Verify that
pipelines.yamlfixture exists and contains a duration panel example with nanosecond values.mission-control/docs/guide/views/queries/configs.md (2)
9-20: Comprehensive query properties documentation.The properties table covers all major filtering and limiting options with clear descriptions. The tagSelector and labelSelector examples are particularly helpful for users unfamiliar with the syntax.
28-38: Well-organized auto-mapped columns reference.The bullet-point format for auto-mapped columns is appropriate and clearly groups related fields (identifiers, state, timestamps, metadata, costs, relationships). This makes it easy for users to find the columns they need.
Verify that the
cronjobs.yamlfixture exists and that lines 32-37 demonstrate a config query with the documented properties. Also confirm that all listed auto-mapped columns (particularly thecost_total_*dfields) are actually available in config query results.mission-control/docs/guide/views/queries/sql.md (1)
1-32: Well-structured SQL Query documentation with practical guidance.The content clearly explains SQL data source configuration, provides a concrete example, and includes actionable tips. The mention of templating aligns well with PR objectives on enhancing Views documentation.
Please verify that the fixture file reference at line 24 (
modules/mission-control/fixtures/views/failing-health-checks.yaml {33-59}) exists and contains valid YAML at those line numbers. I'll generate a verification script to confirm all fixture paths across the documentation changes.mission-control/docs/guide/views/panels/index.mdx (1)
1-38: Excellent index structure for panel documentation.The index page effectively introduces Panels, provides clear definition syntax, documents common properties, and leverages
<DocCardList />for auto-discovery of panel type documentation. This structure supports good discoverability and maintenance.mission-control/docs/guide/views/panels/gauge.md (1)
1-39: Comprehensive Gauge panel documentation.The documentation clearly explains gauge properties, expected data columns, and threshold behavior. The structure is consistent with other panel type documentation and provides the information needed to use the gauge panel effectively.
Verify that the fixture file reference at line 37 (
modules/mission-control/fixtures/views/panels/gauge.yaml) exists and demonstrates valid gauge panel configuration.mission-control/docs/guide/views/queries/prometheus.md (1)
1-45: Clear and practical Prometheus Query documentation.The documentation effectively explains how to query Prometheus, provides column definition guidance, and clearly documents auto-mapped columns (labels and value). The progression from query properties to column definitions to auto-mapped behavior is logical and helpful.
Verify that the fixture file reference at line 19 (
modules/mission-control/fixtures/views/pods.yaml {75-103}) exists and the specified line range contains valid Prometheus query configuration.mission-control/docs/reference/playbooks/events.md (1)
11-11: Table formatting alignment (benign).Lines 11 and 15 contain table column spacing adjustments that are presentational only and don't affect functionality.
Also applies to: 15-15
mission-control/docs/guide/views/panels/number.md (1)
1-33: Well-organized Number panel documentation with progressive examples.The documentation effectively shows basic usage and then demonstrates use with unit and precision options. The Expected Columns section clearly documents the flexibility of accepting either
valueorcountas the numeric column, which is helpful for users.Verify that both fixture file references exist:
- Line 25:
modules/mission-control/fixtures/views/panels/number.yaml- Line 31:
modules/mission-control/fixtures/views/panels/resource-usage.yamlmission-control/docs/guide/views/panels/bargauge.md (1)
1-41: Excellent Bar Gauge panel documentation with practical context.The documentation clearly explains the bar gauge panel, including specialized properties like
group(for organizing related bars) andformat(percentage vs multiplier). The opening use case is helpful context, and the properties and column documentation are comprehensive.Verify that the fixture file reference at line 39 (
modules/mission-control/fixtures/views/panels/bargauge.yaml) exists and demonstrates valid bar gauge panel configuration.mission-control/docs/guide/views/queries/changes.md (1)
1-49: Comprehensive Change Query documentation with excellent Search Syntax guidance.The documentation thoroughly covers change query properties, provides clear auto-mapped column documentation, and includes a practical Search Syntax section with real examples (
change_type=,@order=, and combined filters). This progression effectively guides users from basic to advanced query construction.Verify that the fixture file reference at line 22 (
modules/mission-control/fixtures/views/pipelines.yaml {57-63}) exists and the specified line range contains a valid change query example.mission-control/docs/guide/views/table/columns/index.mdx (1)
1-61: Well-structured new documentation for columns guide.The new columns guide provides a solid foundation for the per-type column documentation. The introduction clearly explains column purpose, the YAML example is well-commented, and the common properties table is comprehensive. The use of
DocCardListto auto-render child pages is a good pattern for maintainability.mission-control/docs/guide/views/index.md (3)
11-23: Clear, feature-focused rewrite of views overview.The reframing from "SQL-powered" to "dynamic, data-driven dashboards" better conveys the multi-source aggregation story. The expanded feature bullet list now explicitly mentions templating, caching, transformation, and embedding—critical capabilities for users. This sets proper context for readers exploring detailed docs.
34-35: Correct addition of SQL and "Other Views" as data sources.Adding SQL and
viewTableSelectoras first-class data sources alongside configs, changes, and Prometheus is accurate per the updated schema reference. This accurately reflects the new capabilities introduced in this PR.
90-104: Good practical examples: Compose Pages and Config Tabs.The two new sections demonstrate real-world use cases (multi-view pages with shared filters, and view-as-tab on config items). The YAML example references are helpful and follow the established documentation pattern. These guide users on how to leverage the new composition and templating features.
mission-control/docs/guide/views/concepts/templating.md (4)
7-70: Excellent introduction and Variables vs Column Filters explanation.The opening clearly articulates the purpose of variables, and the ASCII diagram with the comparison table is exceptional. Distinguishing when variables filter at source-query time (affecting cache) vs when column filters apply at display time is crucial context. The 10K pods example makes this concrete and practical.
72-174: Comprehensive variable types documentation with clear examples.The property reference, three variable types, and worked examples for static, dynamic, and dependent variables are well-organized. The cluster → namespace → pod dependency hierarchy is a great real-world pattern. The topological ordering and circular dependency detection sections give users confidence in the system's robustness.
184-267: Strong coverage of variable usage across all query types.The sections on using variables in configs, Prometheus, and custom merges demonstrate the full scope of the feature. The dependency resolution section (lines 228–267) with caching semantics is important for understanding performance characteristics and cache isolation per variable combination.
266-266: Verify that the./cache-control.mdfile exists in this directory.The link on line 266 references
./cache-control.md, which should be located inmission-control/docs/guide/views/concepts/. Please confirm this file exists to ensure the documentation link is not broken when published.mission-control/docs/reference/views/_view.mdx (5)
1-95: Comprehensive schema reference update with clear structure.The expanded reference now documents all new top-level capabilities (description, display.card, display.plugins, templating, sections) with proper links to guide docs. The validation note clarifying that at least one query is required (unless sections-only) and that either panels or columns must be defined is helpful context.
100-126: Query sources expanded correctly to include SQL and viewTableSelector.The new query types (sql and viewTableSelector) are properly documented with clear descriptions and scheme references. This accurately reflects the expanded data source capabilities introduced in this PR.
166-238: Column type and property documentation is thorough.The expanded types (badge, config_item, labels) and new properties (filter, icon, url, unit, configItem, card) are clearly documented with descriptions and scheme references. This gives users the full surface area of column capabilities.
323-335: Clarify gauge configuration changes and threshold deprecation.Lines 323–329: Gauges'
minandmaxfields now accept strings (to support CEL expressions). This is a meaningful change; please verify the implementation supports this and consider a brief note explaining the motivating use case (e.g., "dynamic min/max based on row data").Lines 332–335: The
thresholds[].valuefield is marked "deprecated" but the alternative is not stated. Should users migrate topercent, or is there another field? A brief explanation would help migration.
429-498: Excellent conceptual sections for complex features.The sections on View Card Layout, Config Tabs, Column Filters, Column URLs, Row Attributes & Grants, View Table Selector, and Sections are well-organized and include helpful YAML examples. These bridge the gap between schema and practical usage.
mission-control/docs/guide/views/table/columns/gauge.md (2)
16-16: Clarifythresholdsproperty format and usage.The description is vague and lacks structural details. Expand to explain: the expected array format, how colors are specified, whether the percent is relative to the min/max range, and whether this field is optional.
Consider referencing a thresholds documentation section (if it exists) or including an example snippet showing the expected structure.
20-21: Verify YAML fixture file reference and line range.Ensure the referenced file
<rootDir>/modules/mission-control/fixtures/views/namespace.yamlexists and that lines 25–38 contain a valid and representative gauge column example.mission-control/docs/guide/views/panels/table.md (2)
11-14: Document column constraint violations and edge cases.The Expected Columns section establishes strict requirements but doesn't clarify behavior when constraints are violated:
- What happens if a query returns no
valuecolumn or multiplevaluecolumns?- What if there are no non-
valuecolumns?- Are additional columns beyond these two ignored, displayed, or cause an error?
Expand the documentation to address these scenarios.
18-19: Verify YAML fixture file reference.Ensure the referenced file
<rootDir>/modules/mission-control/fixtures/views/panels/table.yamlexists and contains a valid table panel example.
| ## Application vs Infrastructure | ||
|
|
||
| Application and infrastucture normally have very different failure scenarios, Application errors are normally due to bugs (that produce exceptions) or performance related problems. When there are problems it becomes immiedatly obvious - page fails to load or starts timing out. Infrastructure health is more often related to configuration errors, drift, permissions and unhealthy dependencies problems can lay latent and be influenced by drift and dependences. | ||
| Application and infrastucture normally have very different failure scenarios, Application errors are normally due to bugs (that produce exceptions) or performance related problems. When there are problems it becomes immiedatly obvious - page fails to load or starts timing out. Infrastructure health is more often related to configuration errors, drift, permissions and unhealthy dependencies problems can lay latent and be influenced by drift and dependences. |
There was a problem hiding this comment.
Fix remaining typos in changed content.
While this PR improves formatting and consistency, several spelling and word-choice errors remain unaddressed in changed sections despite being flagged by the static analysis tool:
- Line 9: "infrastucture" → "infrastructure"; "immiedatly" → "immediately"
- Line 11: "straightforard" → "straightforward"; "methodoligies" → "methodologies"
- Line 19: "oreinted" → "oriented"; grammatically incomplete ("tend be" is missing "to")
- Line 219: "thay" → "that"; "continous" → "continuous"
These corrections align with the PR objective to improve documentation quality.
- Application and infrastucture normally have very different failure scenarios, Application errors are normally due to bugs (that produce exceptions) or performance related problems. When there are problems it becomes immiedatly obvious - page fails to load or starts timing out.
+ Application and infrastructure normally have very different failure scenarios. Application errors are normally due to bugs (that produce exceptions) or performance-related problems. When there are problems it becomes immediately obvious—page fails to load or starts timing out.
- Common application health methodologies include **USE** (**u**tilization, **s**aturation,**e**rrors) and **RED** (**r**quests, **e**rrors, **d**uration) that primarily use metrics (and log/trace derived metrics) that define thresholds for known health states. It is fairly straightforard to define healthy, unhealthy and warning states. These methodoligies struggle with unknown states i.e. we are not receiving any traffic so we don't if there are any errors.
+ Common application health methodologies include **USE** (**u**tilization, **s**aturation, **e**rrors) and **RED** (**r**equests, **e**rrors, **d**uration) that primarily use metrics (and log/trace-derived metrics) that define thresholds for known health states. It is fairly straightforward to define healthy, unhealthy, and warning states. These methodologies struggle with unknown states—for example, we are not receiving any traffic so we don't know if there are any errors.
- Infrastructure errors tend be more state oreinted
+ Infrastructure errors tend to be more state-oriented
- This is example isn't really thay useful, as it needs to be run continous, [canary-checker](https://canarychecker.io/) is a kubernetes health-check platform with support for 30+ check types, The [`kubernetes`](https://canarychecker.io/reference/kubernetes) check uses the `is-healthy` library:
+ This example isn't really that useful, as it needs to be run continuously. [canary-checker](https://canarychecker.io/) is a Kubernetes health-check platform with support for 30+ check types. The [`kubernetes`](https://canarychecker.io/reference/kubernetes) check uses the `is-healthy` library:Also applies to: 11-11, 19-19, 219-219
🧰 Tools
🪛 LanguageTool
[grammar] ~9-~9: Ensure spelling is correct
Context: ...tion vs Infrastructure Application and infrastucture normally have very different failure sc...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...(that produce exceptions) or performance related problems. When there are problem...
(QB_NEW_EN_HYPHEN)
[grammar] ~9-~9: Ensure spelling is correct
Context: ...ems. When there are problems it becomes immiedatly obvious - page fails to load or starts ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In mission-control/blog/state-based-alerting/index.md around lines 9, 11, 19 and
219, fix remaining typos and small grammatical issues in the changed content:
replace "infrastucture" with "infrastructure" and "immiedatly" with
"immediately" on line 9; replace "straightforard" with "straightforward" and
"methodoligies" with "methodologies" on line 11; on line 19 replace "oreinted"
with "oriented" and correct the phrase "tend be" to "tend to be"; on line 219
replace "thay" with "that" and "continous" with "continuous". Ensure
punctuation/spacing remains correct after edits.
|
|
||
| ``` |
There was a problem hiding this comment.
Remove stray code fence marker.
An orphaned closing code fence marker ``` appears at line 498 after the end of the reference links section. This should be removed.
- [KubernetesDeploymentGenerationMismatch](https://samber.github.io/awesome-prometheus-alerts/rules#rule-kubernetes-1-24)
-```🤖 Prompt for AI Agents
In mission-control/blog/state-based-alerting/index.md around lines 497-498,
there is an orphaned closing code-fence marker (``` ) at line 498 that should be
removed; edit the file to delete that stray closing triple-backtick so the
markdown no longer contains an unmatched code fence and save the change.
| | `created_at` | `string` | The time the run is scheduled to start (_in RFC3339_) | | ||
| | `start_time` | `string` | The time the run started (_in RFC3339_) | | ||
| | `end_time` | `string` | The time the run ended (_in RFC3339_) | | ||
| | `created_by` | `string` | The ID of the user that created the run. | |
There was a problem hiding this comment.
Fix grammar: use "who" instead of "that" for person reference.
According to grammar conventions, when referring to a person, use "who" instead of "that".
Apply this diff to fix the grammar:
-| `created_by` | `string` | The ID of the user that created the run. |
+| `created_by` | `string` | The ID of the user who created the run. |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | `created_by` | `string` | The ID of the user that created the run. | | |
| | `created_by` | `string` | The ID of the user who created the run. | |
🧰 Tools
🪛 LanguageTool
[style] ~134-~134: Consider using “who” when you are referring to a person instead of an object.
Context: ...string | The ID of the user that created the run. | |conf...
(THAT_WHO)
🤖 Prompt for AI Agents
In mission-control/docs/guide/playbooks/_api.md around line 134, change the
gender-neutral grammar in the table cell for `created_by` so it uses "who"
instead of "that"; update the description to read "The ID of the user who
created the run." making only that wording change.
| | `exec` | Specify exec of action. | [Exec](./exec) | | | ||
| | `gitops` | Specify gitops of action. | [Gitops](./gitops) | | | ||
| | `http` | Specify http of action. | [Http](./http) | | | ||
| | `sql` | Specify sql of action. | [Sql`](./sql) | | |
There was a problem hiding this comment.
Fix backtick placement in table cell on line 22.
The Markdown link in the sql row has misplaced backticks: [Sql](./sql)should beSql`. The backtick should close before the bracket, not after.
Apply this diff to fix the syntax error:
-| `sql` | Specify sql of action. | [Sql`](./sql) | |
+| `sql` | Specify sql of action. | [Sql](./sql) | |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | `sql` | Specify sql of action. | [Sql`](./sql) | | | |
| | `sql` | Specify sql of action. | [Sql](./sql) | | |
🤖 Prompt for AI Agents
mission-control/docs/guide/playbooks/actions/index.md around line 22: the
Markdown table cell has a misplaced backtick in the link `[Sql`](./sql)`; change
it to `[Sql](./sql)` by moving the closing backtick to enclose only the code
span `sql` and ensure the link text is plain `[Sql]` with the URL `(./sql)`, so
the table cell becomes: `| `sql` | ... | [Sql](./sql) | ... |`.
| | `timeout` | Timeout on this action. | [`Duration`](/docs/reference/types#duration) | | | ||
| | `azureDevopsPipeline` | Trigger a pipeline run | [AzureDevops](/docs/guide/playbooks/actions/azure_devops_pipeline) | | | ||
| | `exec` | Run a script e.g. to use `kubectl` or `aws` `CLIs` | [Exec](/docs/guide/playbooks/actions/exec) | | | ||
| | `github` | Trigger Github Action | [Github Action](/docs/guide/playbooks/actions/github) | | |
There was a problem hiding this comment.
Fix capitalization: "Github" → "GitHub".
The official name of the platform is "GitHub" (with capital H). This appears multiple times around line 86 in the table and link text.
Apply this diff to correct the capitalization:
-| `github` | Trigger Github Action
+| `github` | Trigger GitHub ActionAlso update the link text on the same line and any other occurrences.
Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | | | github | Trigger Github Action ...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | | github | Trigger Github Action ...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | [Github Action](/docs/guide/playbooks/actions/g...
(GITHUB)
[uncategorized] ~86-~86: The official name of this software platform is spelled with a capital “H”.
Context: ... | Github Action ...
(GITHUB)
🤖 Prompt for AI Agents
In mission-control/docs/reference/playbooks/index.md around line 86, fix
incorrect capitalization of "Github" to "GitHub" in the table cell and the link
text; update the display text `github` -> `GitHub`, change "Trigger Github
Action" -> "Trigger GitHub Action", and update the link label `[Github Action]`
-> `[GitHub Action]`; search the file for other occurrences of "Github" and
replace them with "GitHub" to keep capitalization consistent.
| Write a blog post on Flanksource MIssion Control approach to AIops, primarily building a real-time and update to mirror state of cloud resources that can be queried rapidly, plus an advanced graph that builds relationships between resources e.g. Cloudformation -> Auto Scaling Group > EC2 instance and then layers on soft relationsyhips like ebs volumes, subnets, IAM poilcies - For Kubernetes it understands Flux and Gitops being able to build a graph of a Flux Kustomization object creating a HelmRelease CRD, which then creates a deployment -> replicset -> pod and then layeying relationships like services, nodes, PVC, ingress, etc.. | ||
|
|
||
| State based alerting (i.e. whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks that can then proactively collect infomation in a distrubuted fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and pro-acrtive playboks are then fed into the model which tan the recommend futher playbooks to execute. | ||
| State based alerting (i.e. whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks that can then proactively collect infomation in a distrubuted fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and pro-acrtive playboks are then fed into the model which tan the recommend futher playbooks to execute. |
There was a problem hiding this comment.
Fix spelling errors.
Multiple spelling errors will degrade the quality of content generated from this prompt:
- "whene" → "when"
- "traditioanl" → "traditional"
- "infomation" → "information"
- "distrubuted" → "distributed"
- "tan" → "can"
- "futher" → "further"
- "advantag" → "advantage"
-State based alerting (i.e. whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks that can then proactively collect infomation in a distrubuted fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and pro-acrtive playboks are then fed into the model which tan the recommend futher playbooks to execute.
+State based alerting (i.e. when resource self-report failure) and traditional alerts from APM tools trigger playbooks that can then proactively collect information in a distributed fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and proactive playbooks are then fed into the model which can then recommend further playbooks to execute.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| State based alerting (i.e. whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks that can then proactively collect infomation in a distrubuted fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and pro-acrtive playboks are then fed into the model which tan the recommend futher playbooks to execute. | |
| State based alerting (i.e. when resource self-report failure) and traditional alerts from APM tools trigger playbooks that can then proactively collect information in a distributed fashion from agents deployed closest to the data, the graph, changes to the graph resources, events and proactive playbooks are then fed into the model which can then recommend further playbooks to execute. |
🧰 Tools
🪛 LanguageTool
[grammar] ~19-~19: Use a hyphen to join words.
Context: ...vices, nodes, PVC, ingress, etc.. State based alerting (i.e. whene resource self...
(QB_NEW_EN_HYPHEN)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...whene resource self-report failure) and traditioanl alerts from APM tools trigger playbooks...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...books that can then proactively collect infomation in a distrubuted fashion from agents de...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ...hen proactively collect infomation in a distrubuted fashion from agents deployed closest to...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~19-~19: Ensure spelling is correct
Context: ... into the model which tan the recommend futher playbooks to execute. This is advantag...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
In prompts/blog.md around line 19, the sentence contains multiple spelling
mistakes; correct "whene" to "when", "traditioanl" to "traditional",
"infomation" to "information", "distrubuted" to "distributed", "tan" to "can",
and "futher" to "further" (and fix any other nearby typos such as
"playboks"→"playbooks" and "pro-acrtive"→"proactive") so the sentence reads
clearly and correctly while preserving original meaning.
| - Introduction - introduce the topic of the blog with a pain point or teaser | ||
| - Background - Describe the context and initial challenges. | ||
| - Step by step guide | ||
| - Common Pitfalls - Highlight common mistakes and how to avoid them and add use-cases that are not a good fiit | ||
| - Conclustion - Offer final thoughts and potential future implications. |
There was a problem hiding this comment.
Use hyphens to join compound modifiers.
Several phrases need hyphenation per standard English grammar:
- Line 36: "Introduction" section should use a consistent format; context suggests this is fine
- Line 38: "Step by step guide" → "Step-by-step guide"
- Line 39: "Common Pitfalls" section is fine; unclear if "Common-Pitfalls" is intended
- - Introduction - introduce the topic of the blog with a pain point or teaser
- - Background - Describe the context and initial challenges.
- - Step by step guide
+ - Introduction: Introduce the topic of the blog with a pain point or teaser
+ - Background: Describe the context and initial challenges.
+ - Step-by-step guide📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Introduction - introduce the topic of the blog with a pain point or teaser | |
| - Background - Describe the context and initial challenges. | |
| - Step by step guide | |
| - Common Pitfalls - Highlight common mistakes and how to avoid them and add use-cases that are not a good fiit | |
| - Conclustion - Offer final thoughts and potential future implications. | |
| - Introduction: Introduce the topic of the blog with a pain point or teaser | |
| - Background: Describe the context and initial challenges. | |
| - Step-by-step guide | |
| - Common Pitfalls - Highlight common mistakes and how to avoid them and add use-cases that are not a good fiit | |
| - Conclustion - Offer final thoughts and potential future implications. |
🧰 Tools
🪛 LanguageTool
[grammar] ~38-~38: Use a hyphen to join words.
Context: ...ontext and initial challenges. - Step by step guide - Common Pitfalls - Hig...
(QB_NEW_EN_HYPHEN)
[grammar] ~38-~38: Use a hyphen to join words.
Context: ...ext and initial challenges. - Step by step guide - Common Pitfalls - Highli...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
In prompts/blog.md around lines 36 to 40, fix punctuation and typos: change
"Step by step guide" to "Step-by-step guide" (use hyphens for the compound
modifier) and correct "Conclustion" to "Conclusion"; leave "Introduction" and
"Common Pitfalls" as-is but scan nearby lines for any other compound modifiers
that should be hyphenated and apply the same pattern for consistency.
|
|
||
| ## Formating | ||
|
|
||
| - Format all output using MDX (markdowon) |
There was a problem hiding this comment.
Fix typo in formatting requirement.
"markdowon" should be "markdown."
-- Format all output using MDX (markdowon)
+- Format all output using MDX (markdown)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Format all output using MDX (markdowon) | |
| - Format all output using MDX (markdown) |
🤖 Prompt for AI Agents
In prompts/style.md around line 9, the formatting requirement has a typo
"markdowon"; change it to "markdown" so the line reads "Format all output using
MDX (markdown)". Ensure spelling is corrected and commit the updated file.
✅ Deploy Preview for canarychecker canceled.
|
resolves: #438
Summary by CodeRabbit
Documentation
New Content
Updates & Improvements
✏️ Tip: You can customize this high-level summary in your review settings.