Pr/changes #458
Pr/changes #458
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for canarychecker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Warning Rate limit exceeded@moshloop has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 11 minutes and 27 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (62)
WalkthroughThis PR adds comprehensive documentation for request chaining and configuration scraper features, reorganizes scraper documentation with updated sidebar ordering, removes hardcoded table-of-contents exports from integration pages, and updates component anchoring for better documentation linking. Changes
Possibly related PRs
🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 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: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (7)
mission-control/docs/guide/config-db/scrapers/azure.md (1)
12-12: Fix grammatical error in description.The sentence has a subject-verb disagreement: "scrapers scrapes" should be "scraper scrapes." Also, "azure" should be capitalized as "Azure."
Suggested fix
-The Azure scrapers scrapes your azure account to fetch all the resources & save them as configs. +The Azure scraper scrapes your Azure account to fetch all the resources and saves them as configs.mission-control/docs/guide/config-db/scrapers/trivy.mdx (2)
60-60: Remove duplicate import statement.This import statement is a duplicate of line 8 and appears to be misplaced at the end of the table definition.
Suggested fix
-import { Trivy } from "@flanksource/icons/mi"
19-19: Fix typos in description.The sentence contains two typos: "scrapper" should be "scraper" and "scape" should be "scrape."
Suggested fix
-Unlike other scrapers, this one does not scape new configs but rather look for security vulnerabilities in the existing configs. This scrapper, if configured to scan a kubernetes cluster, will map all the found vulnerabilities to the corresponding config item. +Unlike other scrapers, this one does not scrape new configs but rather looks for security vulnerabilities in the existing configs. This scraper, if configured to scan a Kubernetes cluster, will map all the found vulnerabilities to the corresponding config item.mission-control/docs/guide/config-db/scrapers/gcp.mdx (1)
12-12: Fix grammatical error in description.Similar to other scraper docs, this has a subject-verb disagreement: "scrapers scrapes" should be "scraper scrapes."
Suggested fix
-The GCP scrapers scrapes your GCP account to fetch all the resources & save them as configs. +The GCP scraper scrapes your GCP account to fetch all the resources and saves them as configs.mission-control/docs/reference/playbooks/events.md (3)
5-5: Fix passive voice and grammar error.The sentence uses passive voice ("can be triggered") and has a grammar error ("when specific occurs" is incomplete).
Per coding guidelines, documentation must use active voice. Additionally, the phrase "when specific occurs" is missing a noun.
✍️ Suggested fix
-Playbook can be triggered when specific occurs, e.g. you can trigger a playbook to run when a component becomes unhealthy. +Trigger a playbook when specific events occur, e.g. run a playbook when a component becomes unhealthy.Based on coding guidelines requiring active voice.
7-7: Replace passive voice with active voice.The phrase "it is triggered" uses passive voice, which violates the coding guidelines requiring active voice throughout documentation.
✍️ Suggested fix
-Multiple playbooks could be listening to the same event and likewise a playbook can be listening to multiple events. If a playbook is listening on multiple events then it is triggered when any of those events occur. +Multiple playbooks can listen to the same event, and a single playbook can listen to multiple events. When a playbook listens to multiple events, any of those events triggers the playbook.Based on coding guidelines requiring active voice.
55-74: Correct the component type to remove documentation path.The example uses
/docs/guide/canary-checker/reference/databaseas the component type, which appears to be a documentation path mistakenly used instead of a simple component type identifier.Component types should be simple identifiers like
database,api,service, etc., not documentation paths. This example will not work correctly as written.🔧 Suggested fix
-```yaml title="notify-unhealthy-/docs/guide/canary-checker/reference/database-component.yaml" +```yaml title="notify-unhealthy-database-component.yaml" apiVersion: mission-control.flanksource.com/v1 kind: Playbook metadata: - name: notify-unhealthy-/docs/guide/canary-checker/reference/database-component + name: notify-unhealthy-database-component spec: - description: Notify when a /docs/guide/canary-checker/reference/database component goes unhealthy + description: Notify when a database component goes unhealthy on: component: - event: unhealthy - filter: component.type == '/docs/guide/canary-checker/reference/database' + filter: component.type == 'database' labels: env: production
🤖 Fix all issues with AI agents
In @canary-checker/docs/concepts/request-chaining.mdx:
- Line 24: The docs page request-chaining.mdx references a non-existent fixture
(http_depends_on_pass.yaml) inside the code block titled "http-depends-on.yaml";
fix this by either initializing the canary-checker submodule so
modules/canary-checker/fixtures/minimal/http_depends_on_pass.yaml exists, or
update the code block to point to the correct existing fixture path or embed the
fixture contents inline (modify the ```yaml title="http-depends-on.yaml"
file=... line accordingly) so the documentation builds cleanly.
In @mission-control/docs/guide/config-db/scrapers/logs.mdx:
- Around line 105-135: Replace every opening <details summary="..."> tag used in
the docs with a proper HTML details block that separates the summary attribute
into a nested <summary> element: change the single-tag form <details
summary="Example text"> to an opening <details> followed immediately by a
<summary> containing the same text, leaving the inner fenced code block or
content unchanged and keeping the closing </details> as-is; apply this fix to
each occurrence of the shorthand details tag in the file (the examples that
currently use <details summary="...">).
In @mission-control/docs/guide/playbooks/actions/logs.mdx:
- Line 77: Replace every malformed details element that uses a summary attribute
(e.g., <details summary="...">) with a proper nested summary child: open
<details> with no attributes, immediately add a <summary> element containing the
summary text, then close the summary and continue the content inside the details
block; apply this change to all occurrences of the invalid pattern in the file
so each details/summary pair follows the correct HTML structure.
- Line 159: The filter is using mission-control's high-level health field
`config.status` which only carries Healthy/Progressing/Terminated; replace it
with a check against the raw Kubernetes pod container status fields (e.g.,
inspect `config.status.containerStatuses` and match the container state reason
like `state.waiting.reason == "CrashLoopBackOff"` or check each
containerStatus.reason) so the filter detects CrashLoopBackOff; update the
filter expression in logs.mdx to traverse `config.status.containerStatuses` and
match the container-level reason accordingly.
In @mission-control/docs/installation/self-hosted/getting-started.mdx:
- Line 57: In mission-control/docs/installation/self-hosted/getting-started.mdx
there's a link targeting the missing SSO doc
(/docs/installation/self-hosted/sso); either remove that SSO link from
getting-started.mdx or add the missing SSO documentation file (with appropriate
frontmatter and content) and ensure the link href and sidebar/TOC entries point
to the new file.
🧹 Nitpick comments (8)
canary-checker/docs/partials/_gotemplate.md (1)
23-23: Consider using second person for consistency with Google Style Guide.The imperative form "Alternatively change the templating delimiters (see below)" is clear and active, but Google Style Guide recommends second person where possible. Consider rephrasing to "Alternatively, you can change the templating delimiters (see below)" for improved consistency with technical writing standards.
This change properly removes the broken/missing anchor reference and clarifies the link target, which aligns well with the PR's goal of updating component anchoring throughout the documentation.
Optional refinement for second-person style
-Alternatively change the templating delimiters (see below) +Alternatively, you can change the templating delimiters (see below)mission-control/docs/guide/playbooks/actions/gitops.mdx (1)
95-100: Consider adding usage examples for the new conditional patching feature.The new
iffield for conditional patch application is documented but lacks examples showing how to write CEL expressions. Adding a practical example would help users understand how to leverage this feature effectively.📚 Example usage for conditional patching
Consider adding an example in the Patch section or in the examples at the bottom of the document:
patches: - path: 'deployment.yaml' yq: '.spec.replicas = 3' if: 'config.namespace == "production"' # Only apply in production namespace - path: 'service.yaml' yq: '.spec.type = "LoadBalancer"' if: 'user.email.endsWith("@admin.com")' # Only for admin usersThis would clarify the syntax and demonstrate common use cases for conditional patching.
mission-control/docs/reference/connections/opensearch.mdx (2)
44-51: Consider adding descriptions for credential fields.While the field names are self-explanatory, adding brief descriptions (similar to the other fields) would improve documentation consistency and could clarify supported authentication methods.
📝 Suggested enhancement
{ field: 'username', + description: 'Username for OpenSearch authentication', scheme: 'envvar', }, { field: 'password', + description: 'Password for OpenSearch authentication', scheme: 'envvar', },
52-56: Add security warning for insecureSkipVerify.Consider adding a security warning to the description to highlight the risks of disabling TLS certificate verification, as this can expose connections to man-in-the-middle attacks.
🔒 Suggested enhancement
{ field: 'insecureSkipVerify', - description: 'Skip TLS certificate verification', + description: 'Skip TLS certificate verification (not recommended for production)', scheme: 'bool', },mission-control/docs/guide/config-db/concepts/changes.md (2)
38-40: Use active voice per coding guidelines.The note contains passive voice constructions. Rewrite to use active voice.
Suggested revision
:::note -Fields other than these are ignored. Missing fields are treated as empty. +The scraper ignores fields other than these. It treats missing fields as empty. :::As per coding guidelines, documentation should use active voice; never use passive voice.
92-92: Avoid sentence fragments.This line starts with "And" and is a sentence fragment. Combine it with the previous statement or rewrite as a complete sentence.
Suggested revision
-The scraper stores only the `config` object: +The scraper stores only the `config` object and records the change event separately: ```json { "meta": "this is the actual config that'll be stored." }
-And records the change event separately on that config item.
</details> </blockquote></details> <details> <summary>mission-control/docs/guide/config-db/concepts/access-logs.mdx (2)</summary><blockquote> `19-19`: **Use active voice per coding guidelines.** This sentence uses passive voice ("are stored", "can be queried"). Rewrite using active voice. <details> <summary>Suggested revision</summary> ```diff -Access logs are stored separately from configuration data and can be queried independently for audit purposes. +Mission Control stores access logs separately from configuration data. You can query them independently for audit purposes.As per coding guidelines, documentation should use active voice.
105-105: Use active voice.Rewrite to avoid passive voice ("is enabled").
Suggested revision
-The following scrapers support access log extraction when `full: true` is enabled: +The following scrapers support access log extraction when you enable `full: true`:
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (66)
canary-checker/docs/concepts/request-chaining.mdxcanary-checker/docs/partials/_gotemplate.mdcommon/snippets/_resource-selector.mdxcommon/src/components/CapabilityBadges.jsxcommon/src/components/flanksource/MissionControlPage.jsxmission-control/docs/guide/config-db/concepts/access-logs.mdxmission-control/docs/guide/config-db/concepts/changes.mdmission-control/docs/guide/config-db/concepts/plugins.mdxmission-control/docs/guide/config-db/scrapers/_custom.mdxmission-control/docs/guide/config-db/scrapers/aws.mdxmission-control/docs/guide/config-db/scrapers/azure-devops.mdxmission-control/docs/guide/config-db/scrapers/azure.mdmission-control/docs/guide/config-db/scrapers/clickhouse.mdxmission-control/docs/guide/config-db/scrapers/exec.mdxmission-control/docs/guide/config-db/scrapers/file.mdxmission-control/docs/guide/config-db/scrapers/gcp.mdxmission-control/docs/guide/config-db/scrapers/github.mdmission-control/docs/guide/config-db/scrapers/http.mdxmission-control/docs/guide/config-db/scrapers/index.mdxmission-control/docs/guide/config-db/scrapers/kubernetes-file.mdxmission-control/docs/guide/config-db/scrapers/kubernetes.mdxmission-control/docs/guide/config-db/scrapers/logs.mdxmission-control/docs/guide/config-db/scrapers/mssql.mdxmission-control/docs/guide/config-db/scrapers/postgres.mdxmission-control/docs/guide/config-db/scrapers/pubsub.mdxmission-control/docs/guide/config-db/scrapers/slack.mdxmission-control/docs/guide/config-db/scrapers/sql.mdxmission-control/docs/guide/config-db/scrapers/terraform.mdxmission-control/docs/guide/config-db/scrapers/trivy.mdxmission-control/docs/guide/playbooks/actions/exec.mdxmission-control/docs/guide/playbooks/actions/gitops.mdxmission-control/docs/guide/playbooks/actions/logs.mdxmission-control/docs/installation/index.mdxmission-control/docs/installation/saas/getting-started.mdxmission-control/docs/installation/self-hosted/getting-started.mdxmission-control/docs/integrations/_template.mdxmission-control/docs/integrations/argo.mdxmission-control/docs/integrations/aws/index.mdxmission-control/docs/integrations/azure-ad.mdxmission-control/docs/integrations/azure-devops.mdxmission-control/docs/integrations/azure.mdxmission-control/docs/integrations/clickhouse.mdxmission-control/docs/integrations/crossplane.mdxmission-control/docs/integrations/email.mdxmission-control/docs/integrations/flux/index.mdxmission-control/docs/integrations/gcp.mdxmission-control/docs/integrations/github.mdxmission-control/docs/integrations/gitlab.mdxmission-control/docs/integrations/grafana.mdxmission-control/docs/integrations/helm.mdxmission-control/docs/integrations/http.mdxmission-control/docs/integrations/kubernetes/index.mdxmission-control/docs/integrations/kustomize/index.mdxmission-control/docs/integrations/ldap.mdxmission-control/docs/integrations/loki.mdxmission-control/docs/integrations/mcp.mdxmission-control/docs/integrations/opensearch.mdxmission-control/docs/integrations/postgres.mdxmission-control/docs/integrations/prometheus.mdxmission-control/docs/integrations/slack.mdxmission-control/docs/integrations/sql-server.mdxmission-control/docs/integrations/teams.mdxmission-control/docs/integrations/terraform.mdxmission-control/docs/integrations/trivy.mdxmission-control/docs/reference/connections/opensearch.mdxmission-control/docs/reference/playbooks/events.md
💤 Files with no reviewable changes (26)
- mission-control/docs/integrations/opensearch.mdx
- mission-control/docs/integrations/trivy.mdx
- mission-control/docs/integrations/loki.mdx
- mission-control/docs/integrations/azure.mdx
- mission-control/docs/integrations/mcp.mdx
- mission-control/docs/integrations/azure-devops.mdx
- mission-control/docs/integrations/gcp.mdx
- mission-control/docs/integrations/clickhouse.mdx
- mission-control/docs/integrations/sql-server.mdx
- mission-control/docs/integrations/helm.mdx
- mission-control/docs/integrations/gitlab.mdx
- mission-control/docs/integrations/github.mdx
- mission-control/docs/integrations/kubernetes/index.mdx
- mission-control/docs/integrations/ldap.mdx
- mission-control/docs/integrations/argo.mdx
- mission-control/docs/integrations/teams.mdx
- mission-control/docs/integrations/_template.mdx
- mission-control/docs/integrations/azure-ad.mdx
- mission-control/docs/integrations/postgres.mdx
- mission-control/docs/integrations/flux/index.mdx
- mission-control/docs/integrations/kustomize/index.mdx
- mission-control/docs/integrations/slack.mdx
- mission-control/docs/integrations/grafana.mdx
- mission-control/docs/integrations/email.mdx
- mission-control/docs/integrations/terraform.mdx
- mission-control/docs/integrations/crossplane.mdx
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{md,markdown,txt}
📄 CodeRabbit inference engine (.cursor/rules/global.mdc)
**/*.{md,markdown,txt}: Use Google Style Guide (https://developers.google.com/style) for documentation and writing style
Use active voice; never use passive voice
Files:
mission-control/docs/guide/config-db/concepts/changes.mdmission-control/docs/guide/config-db/scrapers/github.mdcanary-checker/docs/partials/_gotemplate.mdmission-control/docs/guide/config-db/scrapers/azure.mdmission-control/docs/reference/playbooks/events.md
**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
**/*.md: Runmake fmtto format Markdown with Prettier before committing changes
Runmake lintwith Vale and markdownlint to lint documentation before committing changes
Documentation should follow Google style using second person, active voice, and present tense
Files:
mission-control/docs/guide/config-db/concepts/changes.mdmission-control/docs/guide/config-db/scrapers/github.mdcanary-checker/docs/partials/_gotemplate.mdmission-control/docs/guide/config-db/scrapers/azure.mdmission-control/docs/reference/playbooks/events.md
**/*.{js,ts,tsx,jsx,py,java,cs,cpp,c,go,rb,php,scala,kotlin,swift}
📄 CodeRabbit inference engine (.cursor/rules/global.mdc)
Do not write comments in code unless the implementation is not clear
Files:
common/src/components/CapabilityBadges.jsxcommon/src/components/flanksource/MissionControlPage.jsx
**/*.{js,ts,tsx,jsx,json}
📄 CodeRabbit inference engine (.cursor/rules/global.mdc)
Use only the following icons from the available icon library: access-denied.svg, activemq.svg, activity-feed-o.svg, activity-feed.svg, activity.svg, add-alarm-clock.svg, add-alarm.svg, add-alert.svg, add-certificate.svg, add-clock.svg, add-cloud.svg, add-cost.svg, add-database.svg, add-disk.svg, add-email.svg, add-firewall.svg, add-folder.svg, add-group.svg, add-heart.svg, add-inbox.svg, add-key.svg, add-list.svg, add-network-card.svg, add-node.svg, add-page.svg, add-properties.svg, add-receipt.svg, add-shield.svg, add-snapshot.svg, add-tag.svg, add-ticket.svg, add-user.svg, add.svg, and 500+ additional icons from the icon library
Files:
common/src/components/CapabilityBadges.jsxcommon/src/components/flanksource/MissionControlPage.jsx
🪛 LanguageTool
common/snippets/_resource-selector.mdx
[style] ~18-~18: To form a complete sentence, be sure to include a subject or ‘there’.
Context: ..., and for components it's the topology. Can be a UUID or namespace/name ...
(MISSING_IT_THERE)
🔇 Additional comments (47)
mission-control/docs/guide/config-db/scrapers/azure-devops.mdx (1)
1-6: LGTM!The sidebar position update is minimal and aligns with the PR's documentation reorganization effort. The front matter is correct.
mission-control/docs/guide/config-db/scrapers/slack.mdx (1)
3-3: LGTM! Documentation sidebar reordering.The sidebar position update is part of the broader documentation reorganization effort mentioned in the PR context.
mission-control/docs/guide/config-db/scrapers/pubsub.mdx (2)
1-6: LGTM!The frontmatter updates are consistent: the icon name change to
gcp-pubsubbetter reflects that this scraper is GCP-specific, and the sidebar position adjustment aligns with the broader documentation reorganization.
10-10: LGTM!The icon name in the heading is consistent with the frontmatter
iconproperty update.common/src/components/CapabilityBadges.jsx (2)
8-8: LGTM! Anchor properties added for documentation linking.The anchor properties are consistently named using kebab-case and will enable proper deep linking to documentation sections.
Also applies to: 16-16, 24-24, 32-32, 40-40, 48-48
89-89: LGTM! Anchor navigation and visual hierarchy improvements.The
idattribute on the h2 element enables deep linking to specific capability sections, improving navigation and accessibility. The icon size increase (w-5 h-5 vs w-4 h-4 in badges) appropriately establishes visual hierarchy between headings and inline badges.Also applies to: 98-98
mission-control/docs/guide/config-db/concepts/plugins.mdx (2)
40-45: LGTM! Field definition is well-structured.The new
retentionfield follows the same pattern as other field definitions, with a clear description and appropriate schema reference.
81-104: Link target verified—no issues found.The retention documentation exists at the expected location, and the
./retentionlink reference is valid. The Retention section content is well-written with clear explanations and a helpful YAML example demonstrating the key configuration features.mission-control/docs/installation/saas/getting-started.mdx (1)
25-25: LGTM!The link reference is correct and aligns with the updated slug structure in the self-hosted documentation.
mission-control/docs/installation/self-hosted/getting-started.mdx (1)
3-3: Verify redirect configuration for the slug change.The slug has been simplified from
/installation/self-hosted/getting-startedto/installation/self-hosted, which is a cleaner URL structure. However, this breaks existing links and bookmarks.Ensure that a redirect is configured in your documentation framework (e.g., Docusaurus redirects plugin) to maintain backward compatibility:
- From:
/installation/self-hosted/getting-started- To:
/installation/self-hostedmission-control/docs/installation/index.mdx (1)
46-46: Link update correctly removes old slug without breaking references.The updated link pointing to
/docs/installation/self-hostedis correct and no remaining references to the old path exist in the documentation.mission-control/docs/guide/config-db/scrapers/clickhouse.mdx (3)
3-3: Documentation reorganization looks good.The sidebar position change from 7 to 5 moves this scraper documentation earlier in the navigation, which aligns with the PR's objective to reorganize scraper documentation with updated sidebar ordering.
302-302: Nice documentation enhancement!Adding a reference to the Access Logs documentation provides helpful context for users who need more details on the access log schema. This improves the documentation quality and user experience.
6-6: The icon referencesimple-icons:clickhouseis valid and exists in the simple-icons library. No action required.mission-control/docs/guide/playbooks/actions/logs.mdx (6)
15-38: LGTM! Excellent introductory example.The example effectively demonstrates the Logs action with practical downstream usage (AI analysis), proper templating, and clear structure.
46-58: LGTM! Clear and comprehensive field definitions.The field definitions are well-organized with helpful examples inline and appropriate type schemes.
122-199: Excellent comprehensive examples for Kubernetes logs.The three examples effectively cover different retrieval patterns (specific pod, crashed container, label selector) and demonstrate proper field usage.
201-238: LGTM! Well-documented Loki integration.The Loki section includes proper field definitions and a practical example demonstrating LogQL queries with CEL-based post-filtering.
240-283: LGTM! Comprehensive OpenSearch documentation.The section effectively demonstrates OpenSearch/Elasticsearch integration with proper query syntax and field mapping examples.
285-311: LGTM! Clear output documentation with practical examples.The output section effectively demonstrates result structure and downstream action integration with conditional execution.
mission-control/docs/guide/config-db/scrapers/terraform.mdx (1)
3-3: LGTM!The sidebar position update to 19 aligns with the broader navigation reordering across scraper documentation.
mission-control/docs/guide/config-db/scrapers/azure.md (1)
3-3: LGTM!The sidebar position update to 3 is consistent with the navigation reordering.
mission-control/docs/guide/config-db/scrapers/kubernetes.mdx (1)
3-3: LGTM!The sidebar position update to 11 is consistent with the documentation navigation reordering.
mission-control/docs/guide/config-db/scrapers/github.md (1)
4-4: LGTM!The sidebar position update to 9 aligns with the navigation reordering.
mission-control/docs/guide/config-db/scrapers/trivy.mdx (1)
3-3: LGTM!The sidebar position update to 20 is consistent with the navigation reordering.
mission-control/docs/guide/config-db/scrapers/gcp.mdx (1)
3-3: LGTM!The sidebar position update to 8 is consistent with the navigation reordering.
mission-control/docs/guide/config-db/scrapers/aws.mdx (1)
3-3: LGTM!The sidebar position update to 2 is consistent with the documentation navigation reordering.
mission-control/docs/integrations/http.mdx (1)
125-136: LGTM!The new Request Chaining section follows Google Style Guide with active voice, present tense, and clear, concise language.
mission-control/docs/integrations/prometheus.mdx (1)
114-114: LGTM!The link update follows active voice style guidelines and improves the documentation path structure.
mission-control/docs/reference/playbooks/events.md (1)
1-103: Revise documentation for active voice and fix content issues, then run formatting and linting tools.The documentation contains passive voice constructions that violate the Google Style Guide. Specifically:
- "Playbook can be triggered when specific occurs" should be rewritten in active voice (e.g., "Trigger a playbook when a specific event occurs")
- The example title "notify-unhealthy-/docs/guide/canary-checker/reference/database" appears malformed and should be a descriptive title
- Remove duplicate event tables in the Canary section
After making these revisions, run
make fmtto format with Prettier andmake lintto lint with Vale and markdownlint.mission-control/docs/guide/playbooks/actions/exec.mdx (2)
130-131: LGTM: Field metadata consistency improvement.The change from
typetoschemefor thedestinationfield improves consistency with other field definitions throughout the documentation. The addition of thedepthfield for shallow clones is a useful enhancement.
147-147: No issues found. The documentation is accurate:
- PEP 723 is a Final specification that defines inline script metadata for Python scripts exactly as described.
- Link references a legitimate Python packaging documentation source.
uvpackage manager is a real, actively maintained tool available for Python environment and dependency management.mission-control/docs/guide/config-db/scrapers/exec.mdx (2)
85-98: Good: Consistent Setup documentation across scraper and playbook actions.The Setup section structure and RuntimeSetup schema are consistent with the playbook exec action documentation, which improves maintainability and user experience.
33-33: Verify the referenced fixture file exists in the config-db repository.The documentation references
exec-backstage-catalog.yamlat<rootDir>/modules/config-db/fixtures/exec-backstage-catalog.yaml. This fixture file is located in the config-db submodule and could not be verified in the sandbox environment. Ensure this file exists in the config-db repository at the referenced path.canary-checker/docs/concepts/request-chaining.mdx (2)
42-76: Well-documented: Clear output access patterns and practical example.The documentation clearly explains how to access outputs from dependent checks using the
outputs.<checkName>.<field>pattern, and the authentication flow example demonstrates a real-world use case effectively.
86-90: Good: Clear limitations prevent common pitfalls.The limitations section appropriately warns users about circular dependencies and scope constraints, helping prevent configuration errors.
mission-control/docs/integrations/aws/index.mdx (1)
49-50: Documentation links are correctly updated and valid.Both the S3 and CloudWatch health check documentation links point to valid files with the expected content. The S3 section exists in the folder documentation (line 107), and the CloudWatch documentation is properly structured.
mission-control/docs/guide/config-db/scrapers/sql.mdx (1)
50-50: Documentation links in thefullfield are valid.Both referenced concept pages exist with the expected content:
/docs/guide/config-db/concepts/changes#extracting-changes— the anchor "Extracting Changes" is defined in changes.md/docs/guide/config-db/concepts/access-logs— the page exists and documents access log trackingcommon/snippets/_resource-selector.mdx (1)
3-26: LGTM!The updated resource selector documentation is comprehensive and well-structured. The field descriptions are clear, and the table provides excellent reference material for users. The addition of wildcards, negation, and search syntax documentation significantly improves usability.
mission-control/docs/guide/config-db/scrapers/file.mdx (1)
38-38: LGTM!The
fullfield description now properly links to the changes and access-logs concept pages, providing users with easy navigation to related documentation.mission-control/docs/guide/config-db/scrapers/http.mdx (1)
3-3: LGTM!The sidebar position update and the
fullfield description linking to the changes and access-logs concept pages are consistent with the broader documentation reorganization in this PR.Also applies to: 25-25
mission-control/docs/guide/config-db/scrapers/mssql.mdx (1)
464-464: LGTM!The addition of the Access Logs reference in the SQL Server Audit Logs section provides helpful cross-linking to the new concept documentation.
mission-control/docs/guide/config-db/scrapers/postgres.mdx (1)
3-3: LGTM!The sidebar position update and Access Logs reference in the pg_audit section are consistent with the documentation patterns established in other scraper files.
Also applies to: 408-408
mission-control/docs/guide/config-db/scrapers/_custom.mdx (1)
96-98: LGTM!The updated "Extracting Changes & Access Logs" section appropriately delegates to the dedicated concept pages rather than duplicating content. This improves maintainability and ensures users get the most up-to-date information from the canonical sources.
mission-control/docs/guide/config-db/concepts/changes.md (1)
27-109: New documentation section looks comprehensive.The "Extracting Changes" section provides clear examples, a well-structured schema table, and proper cross-references to related documentation. The JSON and YAML examples effectively demonstrate the feature.
mission-control/docs/guide/config-db/concepts/access-logs.mdx (2)
1-130: Well-structured new documentation page.The access logs documentation provides comprehensive coverage including:
- Clear overview of purpose and use cases
- Practical YAML configuration example
- Detailed schema definition with the Fields component
- JSON example demonstrating real-world usage
- Cross-references to related scrapers and documentation
The structure follows good documentation practices with logical section ordering.
107-116: No action needed. All referenced scraper documentation files exist at the expected paths: sql, postgres, mssql, clickhouse, http, file, and exec.Likely an incorrect or invalid review comment.
|
|
||
| ## Example | ||
|
|
||
| ```yaml title="http-depends-on.yaml" file=<rootDir>/modules/canary-checker/fixtures/minimal/http_depends_on_pass.yaml |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify that the referenced fixture file exists
echo "=== Checking for http_depends_on_pass.yaml ==="
fd -t f "http_depends_on_pass.yaml" modules/canary-checker/fixtures/
# If found, show the content
if fd -t f "http_depends_on_pass.yaml" modules/canary-checker/fixtures/ | grep -q .; then
echo "=== File content ==="
fd -t f "http_depends_on_pass.yaml" modules/canary-checker/fixtures/ -x cat {}
fiRepository: flanksource/docs
Length of output: 363
🏁 Script executed:
#!/bin/bash
# Search for the fixture file across the repository
echo "=== Searching for http_depends_on_pass.yaml ==="
fd -t f "http_depends_on_pass.yaml"
echo ""
echo "=== Searching for fixtures directory ==="
fd -t d "fixtures"
echo ""
echo "=== Checking repository structure ==="
ls -la | head -20Repository: flanksource/docs
Length of output: 1367
🏁 Script executed:
#!/bin/bash
# Check git submodules
echo "=== .gitmodules content ==="
cat .gitmodules
echo ""
echo "=== Looking for request-chaining.mdx ==="
fd -t f "request-chaining.mdx"
echo ""
echo "=== Reading request-chaining.mdx ==="
if fd -t f "request-chaining.mdx" | head -1 | xargs -I {} cat -n {}; then
echo "File found and displayed"
fiRepository: flanksource/docs
Length of output: 4727
🏁 Script executed:
#!/bin/bash
# Check if modules/canary-checker exists and search for the fixture file
echo "=== Checking modules/canary-checker directory ==="
if [ -d "modules/canary-checker" ]; then
echo "canary-checker submodule exists"
ls -la modules/canary-checker/ | head -20
else
echo "canary-checker submodule not initialized"
fi
echo ""
echo "=== Searching for fixtures/minimal directory ==="
if [ -d "modules/canary-checker" ]; then
find modules/canary-checker -type d -name "minimal" 2>/dev/null
fi
echo ""
echo "=== Searching for http_depends_on_pass.yaml in submodule ==="
if [ -d "modules/canary-checker" ]; then
find modules/canary-checker -name "http_depends_on_pass.yaml" 2>/dev/null
fi
echo ""
echo "=== Listing all yaml files in fixtures ==="
if [ -d "modules/canary-checker/fixtures" ]; then
find modules/canary-checker/fixtures -name "*.yaml" 2>/dev/null | head -20
fiRepository: flanksource/docs
Length of output: 406
Fixture file reference is broken.
The example on line 24 references http_depends_on_pass.yaml at modules/canary-checker/fixtures/minimal/http_depends_on_pass.yaml, but this file does not exist. The canary-checker submodule is not initialized, and no fixtures directory is present. Either initialize the submodule or verify that the correct fixture file path exists before this documentation can be built.
🤖 Prompt for AI Agents
In @canary-checker/docs/concepts/request-chaining.mdx at line 24, The docs page
request-chaining.mdx references a non-existent fixture
(http_depends_on_pass.yaml) inside the code block titled "http-depends-on.yaml";
fix this by either initializing the canary-checker submodule so
modules/canary-checker/fixtures/minimal/http_depends_on_pass.yaml exists, or
update the code block to point to the correct existing fixture path or embed the
fixture contents inline (modify the ```yaml title="http-depends-on.yaml"
file=... line accordingly) so the documentation builds cleanly.
| <div className="flex flex-col sm:flex-row gap-4 mb-8"> | ||
| <Link | ||
| to="/docs/mission-control" | ||
| to="/docs" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's verify the file exists and check the actual code at the specified lines
head -1 common/src/components/flanksource/MissionControlPage.jsx | wc -l
wc -l common/src/components/flanksource/MissionControlPage.jsxRepository: flanksource/docs
Length of output: 122
🏁 Script executed:
# Check the specific lines mentioned in the review
sed -n '148,152p' common/src/components/flanksource/MissionControlPage.jsx
sed -n '376,380p' common/src/components/flanksource/MissionControlPage.jsx
sed -n '386,390p' common/src/components/flanksource/MissionControlPage.jsx
sed -n '396,400p' common/src/components/flanksource/MissionControlPage.jsx
sed -n '707,711p' common/src/components/flanksource/MissionControlPage.jsxRepository: flanksource/docs
Length of output: 1063
🏁 Script executed:
# Search for documentation structure - look for docs directory and its structure
find . -type d -name "docs" | head -20Repository: flanksource/docs
Length of output: 111
🏁 Script executed:
# Check what files exist in the docs directory
fd -t f --path "*docs*" "\.(md|mdx)$" | grep -E "(docs/index|docs/installation|docs/guide)" | head -30Repository: flanksource/docs
Length of output: 293
🏁 Script executed:
# Let's find documentation files more correctly
find . -type f -name "*.md" -o -name "*.mdx" | grep -E "(docs/|installation|playbooks|canary-checker)" | head -30Repository: flanksource/docs
Length of output: 1496
🏁 Script executed:
# Check the structure of the docs directory
ls -la docs/ 2>/dev/null || echo "docs directory not found at root"Repository: flanksource/docs
Length of output: 745
🏁 Script executed:
# Look for index files in docs
find docs -maxdepth 2 -name "index.*" -o -name "README.*" 2>/dev/nullRepository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Search for any references to the old mission-control paths
rg "mission-control" --type js --type jsx --type tsx --type ts -n common/src/Repository: flanksource/docs
Length of output: 87
🏁 Script executed:
# Let's look at the actual structure of docs directory more carefully
find docs -type f -name "*.md" -o -name "*.mdx" 2>/dev/null | head -20Repository: flanksource/docs
Length of output: 741
🏁 Script executed:
# Check mission-control/docs structure
find mission-control/docs -type f -name "*.md" -o -name "*.mdx" 2>/dev/null | head -30Repository: flanksource/docs
Length of output: 1642
🏁 Script executed:
# Check if there's a guide directory
find . -maxdepth 3 -type d -name "guide" 2>/dev/nullRepository: flanksource/docs
Length of output: 88
🏁 Script executed:
# Let's check if there's any playbooks documentation
find . -type f -name "*playbook*" 2>/dev/nullRepository: flanksource/docs
Length of output: 1620
🏁 Script executed:
# Check docusaurus config or similar to understand routing
find . -maxdepth 2 -type f \( -name "docusaurus.config.js" -o -name "sidebars.js" -o -name "mkdocs.yml" -o -name "docusaurus.json" \) 2>/dev/nullRepository: flanksource/docs
Length of output: 156
🏁 Script executed:
# Let's check the sidebars configuration to understand routing
cat mission-control/sidebars.js | head -100Repository: flanksource/docs
Length of output: 2044
🏁 Script executed:
# Check if there's documentation at the exact paths referenced in the code
find . -path "*/docs/installation*" -type f 2>/dev/null
find . -path "*/docs/guide/playbooks*" -type f 2>/dev/null
find . -path "*/docs/guide/canary-checker*" -type f 2>/dev/nullRepository: flanksource/docs
Length of output: 4198
🏁 Script executed:
# Let's see what canary-checker installation looks like
find canary-checker/docs -name "*installation*" -o -name "*install*" 2>/dev/nullRepository: flanksource/docs
Length of output: 92
🏁 Script executed:
# Check the main docs directory more thoroughly
ls -la docs/ | head -30Repository: flanksource/docs
Length of output: 745
🏁 Script executed:
# Check if there's a root docusaurus config
cat docusaurus.config.js 2>/dev/null | head -150Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Let's look for any routing/configuration that might map /docs to mission-control
find . -maxdepth 1 -name "*.config.js" -o -name "*.config.json" -o -name "docusaurus.config.js" 2>/dev/null | xargs ls -la 2>/dev/nullRepository: flanksource/docs
Length of output: 2775
🏁 Script executed:
# Check the actual URL structure - look at mission-control docusaurus config
cat mission-control/docusaurus.config.js 2>/dev/null | grep -A 5 -B 5 "routeBasePath\|baseUrl\|url" | head -50Repository: flanksource/docs
Length of output: 42
Fix broken documentation links — paths do not exist in current repository structure.
The updated paths in the navigation links do not correspond to existing documentation files:
/docs/installation→ should be/mission-control/installation(docs found atmission-control/docs/installation/)/docs/guide/playbooks→ should be/mission-control/guide/playbooks(docs found atmission-control/docs/guide/playbooks/)/docs/guide/canary-checker→ does not exist in repository; canary-checker docs are atcanary-checker/docs/, not under a/docs/guide/structure/docs→ no landing page found indocs/root; would require docusaurus routing configuration
Verify the correct documentation URL structure and update the links accordingly, or ensure the deployment/build process configures routing to map these paths to the actual documentation locations.
| <details summary="Example: Normalizing ELK and Loki logs"> | ||
| ```yaml | ||
| apiVersion: configs.flanksource.com/v1 | ||
| kind: ScrapeConfig | ||
| metadata: | ||
| name: unified-app-logs | ||
| spec: | ||
| logs: | ||
| # OpenSearch/Elasticsearch logs use @timestamp and message | ||
| - openSearch: | ||
| url: https://elasticsearch:9200 | ||
| index: app-logs-* | ||
| fieldMapping: | ||
| timestamp: ['@timestamp'] | ||
| message: ['message'] | ||
| severity: ['level', 'log.level'] | ||
| id: ['trace.id', 'request_id'] | ||
|
|
||
| # Loki logs use different field names | ||
| - loki: | ||
| url: http://loki:3100 | ||
| query: '{app="myservice"}' | ||
| fieldMapping: | ||
| timestamp: ['ts', 'timestamp'] | ||
| message: ['line', 'msg'] | ||
| severity: ['level', 'detected_level'] | ||
| id: ['traceID'] | ||
| ``` | ||
| </details> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find and read the logs.mdx file to verify the actual syntax
find . -name "logs.mdx" -type fRepository: flanksource/docs
Length of output: 172
🏁 Script executed:
# Once located, read the specific lines mentioned in the review
cat -n mission-control/docs/guide/config-db/scrapers/logs.mdx | sed -n '105,135p'Repository: flanksource/docs
Length of output: 1061
🏁 Script executed:
# Also check the other lines mentioned (159, 197, 270, 314)
cat -n mission-control/docs/guide/config-db/scrapers/logs.mdx | sed -n '150,165p'
cat -n mission-control/docs/guide/config-db/scrapers/logs.mdx | sed -n '190,205p'
cat -n mission-control/docs/guide/config-db/scrapers/logs.mdx | sed -n '265,280p'
cat -n mission-control/docs/guide/config-db/scrapers/logs.mdx | sed -n '310,325p'Repository: flanksource/docs
Length of output: 1715
🌐 Web query:
Docusaurus MDX details summary tag HTML syntax support
💡 Result:
Short answer: Docusaurus supports using the HTML
tags inside MDX (they render as collapsible blocks and are styled by Docusaurus). Use normal HTML syntax; prefer keeping the on a single line (MDX can insert extra tags on line breaks). Note that putting fenced code blocks or certain Markdown directly inside a
can cause parsing issues — put code/blocks inside the details body, not inside the summary. Examples and guidance below.
Example:
Toggle me!
This is the detailed content.
console.log('code allowed here');
References: Docusaurus docs (Markdown Features / Details). [1][2]
Known parsing/problem discussion about code inside
: Docusaurus GitHub discussion. [3]
Sources:
[1] Docusaurus — Markdown Features / Details.
[2] Docusaurus v3 Markdown Features (details example).
[3] GitHub discussion: “How can I include preformatted json in an expand/collapse section?” (issue/discussion about code inside details/summary).
tags on line breaks). Note that putting fenced code blocks or certain Markdown directly inside a
can cause parsing issues — put code/blocks inside the details body, not inside the summary. Examples and guidance below.
Example:
Toggle me!
This is the detailed content.
console.log('code allowed here');
References: Docusaurus docs (Markdown Features / Details). [1][2]
Known parsing/problem discussion about code inside
: Docusaurus GitHub discussion. [3]
Sources:
[1] Docusaurus — Markdown Features / Details.
[2] Docusaurus v3 Markdown Features (details example).
[3] GitHub discussion: “How can I include preformatted json in an expand/collapse section?” (issue/discussion about code inside details/summary).
Toggle me!
This is the detailed content.console.log('code allowed here');Known parsing/problem discussion about code inside
Sources:
[1] Docusaurus — Markdown Features / Details.
[2] Docusaurus v3 Markdown Features (details example).
[3] GitHub discussion: “How can I include preformatted json in an expand/collapse section?” (issue/discussion about code inside details/summary).
Fix <details> tag syntax throughout the file to use standard HTML structure for Docusaurus compatibility.
The file uses <details summary="..."> syntax, but Docusaurus requires the standard HTML structure with a nested <summary> element. Update lines 105, 159, 197, 270, and 314 to use:
<details>
<summary>Example text here</summary>instead of <details summary="Example text here">.
🤖 Prompt for AI Agents
In @mission-control/docs/guide/config-db/scrapers/logs.mdx around lines 105 -
135, Replace every opening <details summary="..."> tag used in the docs with a
proper HTML details block that separates the summary attribute into a nested
<summary> element: change the single-tag form <details summary="Example text">
to an opening <details> followed immediately by a <summary> containing the same
text, leaving the inner fenced code block or content unchanged and keeping the
closing </details> as-is; apply this fix to each occurrence of the shorthand
details tag in the file (the examples that currently use <details
summary="...">).
| ]}/> | ||
|
|
||
| ### CloudWatch | ||
| <details summary="Example"> |
There was a problem hiding this comment.
Fix invalid HTML syntax for details element.
The <details> tag doesn't support a summary attribute. The <summary> must be a separate child element.
This syntax error appears multiple times in the file (lines 77, 122, 147, 178, 217, 258) and will cause rendering issues.
🔧 Proposed fix for all occurrences
-<details summary="Example">
+<details>
+<summary>Example</summary>Apply this pattern to all affected lines: 77, 122, 147, 178, 217, 258.
For lines 122, 147, 178 with longer summary text:
-<details summary="Example: Fetch logs for a specific pod">
+<details>
+<summary>Example: Fetch logs for a specific pod</summary>📝 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.
| <details summary="Example"> | |
| <details> | |
| <summary>Example</summary> |
🤖 Prompt for AI Agents
In @mission-control/docs/guide/playbooks/actions/logs.mdx at line 77, Replace
every malformed details element that uses a summary attribute (e.g., <details
summary="...">) with a proper nested summary child: open <details> with no
attributes, immediately add a <summary> element containing the summary text,
then close the summary and continue the content inside the details block; apply
this change to all occurrences of the invalid pattern in the file so each
details/summary pair follows the correct HTML structure.
| config: | ||
| - types: | ||
| - Kubernetes::Pod | ||
| filter: config.status == "CrashLoopBackOff" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, read the file context around line 159
wc -l mission-control/docs/guide/playbooks/actions/logs.mdxRepository: flanksource/docs
Length of output: 117
🏁 Script executed:
# Read context around line 159
head -180 mission-control/docs/guide/playbooks/actions/logs.mdx | tail -50Repository: flanksource/docs
Length of output: 1165
🏁 Script executed:
# Search for CrashLoopBackOff patterns in the codebase
rg -n "CrashLoopBackOff" -C 3 --type=yaml --type=mdx --type=mdRepository: flanksource/docs
Length of output: 87
🏁 Script executed:
# Search for config.status patterns to understand config object structure
rg -n "config\.status" --type=yaml --type=mdx --type=md -C 2Repository: flanksource/docs
Length of output: 87
🏁 Script executed:
# Look for playbook examples and on.config section patterns
rg -n "on\.config" --type=yaml --type=mdx --type=md -C 5Repository: flanksource/docs
Length of output: 87
🏁 Script executed:
# Search for config schema or status field definitions
rg -n "config\.status\|config\.phase" --type-list | head -20Repository: flanksource/docs
Length of output: 449
🏁 Script executed:
# Look for schema definitions or config object documentation
rg -n "status.*CrashLoopBackOff\|CrashLoopBackOff.*status" -C 3Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Search for config object property documentation
find . -name "*.md" -o -name "*.mdx" | xargs grep -l "config object\|config properties" 2>/dev/null | head -5Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Look for other filter examples to understand filter syntax patterns
rg -n "filter:\s*config\." --type yaml -C 2 | head -40Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Search in non-documentation code for how status is handled
find . -type f \( -name "*.go" -o -name "*.ts" -o -name "*.js" \) -path "*/mission-control/*" 2>/dev/null | head -5Repository: flanksource/docs
Length of output: 251
🏁 Script executed:
# Read the specific section around line 159 with more context
sed -n '140,180p' mission-control/docs/guide/playbooks/actions/logs.mdxRepository: flanksource/docs
Length of output: 960
🏁 Script executed:
# Read more of the document to find any schema explanations or property definitions
sed -n '1,60p' mission-control/docs/guide/playbooks/actions/logs.mdxRepository: flanksource/docs
Length of output: 2611
🏁 Script executed:
# Search within the mdx file for mentions of "status" or "config" properties
grep -n "status\|config\." mission-control/docs/guide/playbooks/actions/logs.mdx | head -30Repository: flanksource/docs
Length of output: 684
🏁 Script executed:
# Look for any links to schema documentation or references
grep -n "schema\|reference\|config object\|Pod\|Kubernetes" mission-control/docs/guide/playbooks/actions/logs.mdx | head -20Repository: flanksource/docs
Length of output: 1990
🏁 Script executed:
# Find the context.mdx file
find . -name "context.mdx" -o -name "context.md" | head -5Repository: flanksource/docs
Length of output: 114
🏁 Script executed:
# Search for context.mdx in the docs structure
find . -path "*/reference/playbooks/*" -name "*.mdx" -o -name "*.md" | head -10Repository: flanksource/docs
Length of output: 365
🏁 Script executed:
# Look for any documentation about Pod config properties or status mapping
grep -r "config\.status\|Pod status\|config object" mission-control/docs/reference --include="*.md" --include="*.mdx" 2>/dev/null | head -20Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Search the entire docs for documentation about what config represents
grep -r "config is\|config represents\|config contains" mission-control/docs --include="*.md" --include="*.mdx" 2>/dev/null | head -10Repository: flanksource/docs
Length of output: 226
🏁 Script executed:
# Read the context.mdx file to understand the config object
cat mission-control/docs/reference/playbooks/context.mdxRepository: flanksource/docs
Length of output: 4315
🏁 Script executed:
# Find config-db documentation
find . -path "*/docs/reference/config-db*" -type f | head -20Repository: flanksource/docs
Length of output: 335
🏁 Script executed:
# Search for ConfigItem or status field documentation
grep -r "ConfigItem\|status.*Pod\|Pod.*status" mission-control/docs/reference/config-db --include="*.md" --include="*.mdx" 2>/dev/null | head -20Repository: flanksource/docs
Length of output: 42
🏁 Script executed:
# Look for index or main config-db documentation
ls -la mission-control/docs/reference/config-db/ 2>/dev/null | head -20Repository: flanksource/docs
Length of output: 484
🏁 Script executed:
# Read the config.md to understand ConfigItem structure
cat mission-control/docs/reference/config-db/config.mdRepository: flanksource/docs
Length of output: 4638
🏁 Script executed:
# Read properties.md to understand config properties
cat mission-control/docs/reference/config-db/properties.mdRepository: flanksource/docs
Length of output: 3204
🏁 Script executed:
# Search for is-healthy documentation and valid status values
grep -r "is-healthy\|Healthy.*Progressing.*Terminated" mission-control/docs --include="*.md" --include="*.mdx" 2>/dev/null | head -10Repository: flanksource/docs
Length of output: 1241
🏁 Script executed:
# Look for examples of valid config.status values in playbooks
grep -r "config\.status.*==" mission-control/docs --include="*.md" --include="*.mdx" 2>/dev/nullRepository: flanksource/docs
Length of output: 256
🏁 Script executed:
# Find and read the loki.mdx to see the config.status.phase example
grep -n "config\.status" mission-control/docs/integrations/loki.mdx -B 5 -A 5Repository: flanksource/docs
Length of output: 301
🏁 Script executed:
# Search for all filter examples to understand the correct syntax pattern
grep -r "filter:.*config\." mission-control/docs --include="*.md" --include="*.mdx" -B 2 -A 2 | head -50Repository: flanksource/docs
Length of output: 3742
The filter syntax is incorrect and will not match the intended pods.
The value config.status == "CrashLoopBackOff" is invalid. The config.status field (for Kubernetes::Pod types) contains mission-control's health status with values of Healthy, Progressing, or Terminated—not Kubernetes-specific statuses.
To detect pods in CrashLoopBackOff state, access the raw Kubernetes pod data (similar to the filter pattern in loki.mdx: config.status.phase == "Failed"). CrashLoopBackOff is a containerStatus reason and would require examining the pod's container status fields within the raw config object.
🤖 Prompt for AI Agents
In @mission-control/docs/guide/playbooks/actions/logs.mdx at line 159, The
filter is using mission-control's high-level health field `config.status` which
only carries Healthy/Progressing/Terminated; replace it with a check against the
raw Kubernetes pod container status fields (e.g., inspect
`config.status.containerStatuses` and match the container state reason like
`state.waiting.reason == "CrashLoopBackOff"` or check each
containerStatus.reason) so the filter detects CrashLoopBackOff; update the
filter expression in logs.mdx to traverse `config.status.containerStatuses` and
match the container-level reason accordingly.
| <p/> | ||
| > See [Ingress](/docs/reference/helm/mission-control#ingress) for more options on configuring the ingress including generating certs with cert-manager | ||
| > <p>See [Local Testing](../local-testing) for testing using a kind or minikube without a routable domain</p> | ||
| > <p>See [Local Testing](/docs/installation/local-testing) for testing using a kind or minikube without a routable domain</p> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify that all referenced documentation paths exist
# List of paths to check (trying both .mdx and .md extensions)
paths=(
"mission-control/docs/installation/local-testing.mdx"
"mission-control/docs/installation/local-testing.md"
"mission-control/docs/installation/self-hosted/eks.mdx"
"mission-control/docs/installation/self-hosted/eks.md"
"mission-control/docs/installation/self-hosted/database.mdx"
"mission-control/docs/installation/self-hosted/database.md"
"mission-control/docs/installation/self-hosted/sso.mdx"
"mission-control/docs/installation/self-hosted/sso.md"
"mission-control/docs/installation/self-hosted/smtp.mdx"
"mission-control/docs/installation/self-hosted/smtp.md"
)
echo "Checking if referenced documentation files exist..."
for path in "${paths[@]}"; do
if [ -f "$path" ]; then
echo "✓ Found: $path"
fi
done
# Also check the file being edited
echo ""
echo "Checking the file being modified:"
if [ -f "mission-control/docs/installation/self-hosted/getting-started.mdx" ]; then
echo "✓ Found: mission-control/docs/installation/self-hosted/getting-started.mdx"
fiRepository: flanksource/docs
Length of output: 475
Fix broken documentation link to missing SSO file.
Verification of the absolute paths reveals that /docs/installation/self-hosted/sso does not exist. The following files were confirmed:
- ✓
/docs/installation/local-testing(local-testing.md) - ✓
/docs/installation/self-hosted/eks(eks.mdx) - ✓
/docs/installation/self-hosted/database(database.md) - ✗
/docs/installation/self-hosted/sso(missing) - ✓
/docs/installation/self-hosted/smtp(smtp.mdx)
Either remove the SSO link or create the missing documentation file before merging.
🤖 Prompt for AI Agents
In @mission-control/docs/installation/self-hosted/getting-started.mdx at line
57, In mission-control/docs/installation/self-hosted/getting-started.mdx there's
a link targeting the missing SSO doc (/docs/installation/self-hosted/sso);
either remove that SSO link from getting-started.mdx or add the missing SSO
documentation file (with appropriate frontmatter and content) and ensure the
link href and sidebar/TOC entries point to the new file.
|
|
||
| <Cards> | ||
| <Card title="SNS Notifications" link="/docs/guide/notifications/channels/sns" /> | ||
| <Card title="Generic Webhook" link="/docs/guide/notifications/channels/generic" /> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check the structure and find relevant documentation
echo "=== Checking for Generic Webhook documentation ==="
fd -t f "generic" mission-control/docs/ 2>/dev/null || echo "No generic files found with fd"
echo ""
echo "=== Searching for channels directory ==="
find mission-control/docs -type d -name "channels" 2>/dev/null
echo ""
echo "=== List files in notifications/channels directory if it exists ==="
if [ -d "mission-control/docs/guide/notifications/channels" ]; then
ls -la mission-control/docs/guide/notifications/channels/
fi
echo ""
echo "=== Check the main file to understand context ==="
if [ -f "mission-control/docs/integrations/aws/index.mdx" ]; then
cat -n mission-control/docs/integrations/aws/index.mdx | head -100
fiRepository: flanksource/docs
Length of output: 4931
🏁 Script executed:
# Search for SNS references in documentation
echo "=== Searching for SNS references in docs ==="
rg -i "sns|simple.notification" mission-control/docs/ --max-count 20
echo ""
echo "=== Check if there are any AWS-specific notification docs ==="
find mission-control/docs -type f -name "*.mdx" -o -name "*.md" | xargs rg -l "aws.*notif|sns" 2>/dev/null | head -20Repository: flanksource/docs
Length of output: 446
🏁 Script executed:
echo "=== Generic Webhook documentation content ==="
cat mission-control/docs/guide/notifications/channels/generic.mdxRepository: flanksource/docs
Length of output: 3091
Generic Webhook documentation does not cover SNS integration scenarios.
The AWS integration page lists "Publish health check failures to SNS topics" as a use case for notifications, but the linked Generic Webhook documentation provides no SNS-specific guidance. Generic Webhook is designed as a fallback for unsupported targets requiring customization, not as a primary SNS integration method. Consider either:
- Adding SNS-specific guidance to the Generic Webhook documentation, or
- Creating a dedicated SNS notification channel documentation, or
- Removing SNS from the use cases if it's not directly supported.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| let processedLine = line | ||
| .replace(/<[^>]*>/g, '') |
Check failure
Code scanning / CodeQL
Incomplete multi-character sanitization High
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, to fix incomplete multi-character sanitization you either (a) use a robust sanitization library or (b) ensure that any multi-character pattern replacement can’t leave behind new instances of the same unsafe pattern. For HTML/MDX-like text, this often means either using a proper HTML sanitizer or adopting a simpler, character-based approach that consistently escapes or removes dangerous characters such as < and >.
For this specific function, stripMdxToLlms, the intent is to produce a plain-text representation of the docs for LLM consumption, not to preserve HTML formatting. The simplest, least invasive improvement is to keep the existing tag-stripping regex but then additionally escape any remaining < or > characters so that no actual HTML tags can be interpreted by downstream consumers, even if malformed or nested sequences survive the earlier replacement. Escaping transforms < into < and > into >, which preserves the textual content (e.g., showing code like <script> verbatim) while eliminating the possibility of HTML injection.
Implementation details:
- Modify the sanitization chain in
stripMdxToLlms(around lines 91–99) to add a final.replace(/[<>]/g, ...)step that escapes any remaining angle brackets. - Do this after the existing
.replace(/<[^>]*>/g, '')so that normal HTML tags are still removed as currently intended, but any leftover</>characters from code snippets or malformed tags are safely escaped. - No new imports or external libraries are required; this is standard JavaScript string processing confined to
mission-control/scripts/move-llms.js.
| @@ -96,7 +96,8 @@ | ||
| .replace(/:::/g, '') | ||
| .replace(/```yaml title=[^`]*/g, '```yaml') | ||
| .replace(/```go title=[^`]*/g, '```go') | ||
| .replace(/\/\/highlight-next-line/g, ''); | ||
| .replace(/\/\/highlight-next-line/g, '') | ||
| .replace(/[<>]/g, (ch) => (ch === '<' ? '<' : '>')); | ||
|
|
||
| outputLines.push(processedLine); | ||
| } |
Summary by CodeRabbit
Documentation & Features
New Features
Documentation
Updates
✏️ Tip: You can customize this high-level summary in your review settings.