docs: document VictorOps custom_fields in configuration#5184
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds documentation for a new VictorOps receiver field ChangesDocumentation updates (single cohort)
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
must108
force-pushed
the
docs/victorops-custom-fields
branch
from
ac5df6c to
2614e30
Compare
|
@TheMeier are you able to run the workflows, thank you! |
|
@must108 sorry, I don't have the rights for that |
Signed-off-by: Mustaeen Ahmed <136145181+must108@users.noreply.github.com>
SoloJacobs
force-pushed
the
docs/victorops-custom-fields
branch
from
fa065d9 to
e8f6f80
Compare
|
@must108 Thanks for adding the custom_fields documentation. The comment describes these as "fixed/static payload fields", but routing_key is sent as part of the URL path (not the JSON body), and entity_state is not sent at all. The list does correctly reflect what the config validation, but the description is misleading. Could you reword this? |
Signed-off-by: must108 <mustaeen18@gmail.com>
must108
force-pushed
the
docs/victorops-custom-fields
branch
from
bd4f824 to
066f551
Compare
@SoloJacobs resolved, please check! Thank you |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/configuration.md`:
- Around line 1842-1843: Update the explanatory parenthetical that begins "Some
reserved keys are not part of the JSON body, but are still disallowed as
custom_fields keys to avoid conflicts with the integrations request/validation."
Replace the awkward phrase "integrations request/validation" with clearer
wording such as "integration request and validation" (so the full sentence
reads: "Some reserved keys are not part of the JSON body, but are still
disallowed as custom_fields keys to avoid conflicts with the integration request
and validation.") to improve clarity; target the line containing "custom_fields"
and the parenthetical note.
- Around line 49-53: Add a glossary alias for <bool> that mirrors the existing
<boolean> definition so readers aren’t confused by the two forms; update the
placeholder list to include `<bool>` with the same description and regex/values
as `<boolean>` (i.e., a boolean that can take the values `true` or `false`) and
ensure any cross-references in the document (places using `<bool>`) remain
accurate; locate the glossary entries around the existing `<boolean>` and add
the `<bool>` line next to it.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: ddca8fe0-4f6e-40c8-8be2-13f98162ce4e
📒 Files selected for processing (1)
docs/configuration.md
| - `<duration>`: a duration matching the regular expression `((([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)?|0)`, e.g. `1d`, `1h30m`, `5m`, `10s` | ||
| - `<labelname>`: a string matching the regular expression `[a-zA-Z_][a-zA-Z0-9_]*` | ||
| - `<labelvalue>`: a string of unicode characters | ||
| - `<filepath>`: a valid path in the current working directory | ||
| - `<boolean>`: a boolean that can take the values `true` or `false` |
There was a problem hiding this comment.
Add a <bool> alias in the placeholder glossary.
Line 53 defines <boolean>, but the same document frequently uses <bool> (for example, Line 97 and many receiver sections). Defining both in the glossary avoids ambiguity for readers.
✏️ Proposed doc tweak
- `<boolean>`: a boolean that can take the values `true` or `false`
+- `<bool>`: alias of `<boolean>`📝 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.
| - `<duration>`: a duration matching the regular expression `((([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)?|0)`, e.g. `1d`, `1h30m`, `5m`, `10s` | |
| - `<labelname>`: a string matching the regular expression `[a-zA-Z_][a-zA-Z0-9_]*` | |
| - `<labelvalue>`: a string of unicode characters | |
| - `<filepath>`: a valid path in the current working directory | |
| - `<boolean>`: a boolean that can take the values `true` or `false` | |
| - `<duration>`: a duration matching the regular expression `((([0-9]+)y)?(([0-9]+)w)?(([0-9]+)d)?(([0-9]+)h)?(([0-9]+)m)?(([0-9]+)s)?(([0-9]+)ms)?|0)`, e.g. `1d`, `1h30m`, `5m`, `10s` | |
| - `<labelname>`: a string matching the regular expression `[a-zA-Z_][a-zA-Z0-9_]*` | |
| - `<labelvalue>`: a string of unicode characters | |
| - `<filepath>`: a valid path in the current working directory | |
| - `<boolean>`: a boolean that can take the values `true` or `false` | |
| - `<bool>`: alias of `<boolean>` |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/configuration.md` around lines 49 - 53, Add a glossary alias for <bool>
that mirrors the existing <boolean> definition so readers aren’t confused by the
two forms; update the placeholder list to include `<bool>` with the same
description and regex/values as `<boolean>` (i.e., a boolean that can take the
values `true` or `false`) and ensure any cross-references in the document
(places using `<bool>`) remain accurate; locate the glossary entries around the
existing `<boolean>` and add the `<bool>` line next to it.
| # (Some reserved keys are not part of the JSON body, but are still disallowed | ||
| # as custom_fields keys to avoid conflicts with the integrations request/validation.) |
There was a problem hiding this comment.
Tighten wording in the VictorOps reserved-key note.
Line 1843 reads a bit awkwardly (“integrations request/validation”). Rephrasing improves clarity in this newly added explanatory note.
✏️ Proposed wording fix
-# as custom_fields keys to avoid conflicts with the integrations request/validation.)
+# as custom_fields keys to avoid conflicts with the integration's request/validation logic.)📝 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.
| # (Some reserved keys are not part of the JSON body, but are still disallowed | |
| # as custom_fields keys to avoid conflicts with the integrations request/validation.) | |
| # (Some reserved keys are not part of the JSON body, but are still disallowed | |
| # as custom_fields keys to avoid conflicts with the integration's request/validation logic.) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/configuration.md` around lines 1842 - 1843, Update the explanatory
parenthetical that begins "Some reserved keys are not part of the JSON body, but
are still disallowed as custom_fields keys to avoid conflicts with the
integrations request/validation." Replace the awkward phrase "integrations
request/validation" with clearer wording such as "integration request and
validation" (so the full sentence reads: "Some reserved keys are not part of the
JSON body, but are still disallowed as custom_fields keys to avoid conflicts
with the integration request and validation.") to improve clarity; target the
line containing "custom_fields" and the parenthetical note.
SoloJacobs
left a comment
SoloJacobs
left a comment
There was a problem hiding this comment.
I am a bit confused: Why did you reformat the configuration? That does not seem necessary.
3 participants
Summary
custom_fieldsundervictorops_configindocs/configuration.mdcustom_fieldskeys must not overlap with fixed VictorOps payload fieldsRelated to prometheus/docs#2014
Why
custom_fieldsis supported in Alertmanager's VictorOps notifier config, but was missing from the configuration reference. This updates the docs so users can discover and use the field directly from the official docs.Summary by CodeRabbit
New Features
Documentation