Support '/' and '-' in braced template placeholders#2098
Conversation
Kubernetes label and annotation keys routinely contain '/' (prefix
separator) and '-', e.g. app.kubernetes.io/name or com.example/job-count.
ExtendedTemplate's idpattern only allows [_a-z0-9.], so a placeholder like
${annotations.com.example/job-count} never matches and is left verbatim
in the output of format_event_templated_string.
Extend only the braced form via braceidpattern so unbraced placeholders
(e.g. $name-suffix) keep their existing behavior.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe PR broadens braced template placeholder identifiers by adding ChangesTemplate Placeholder Enhancement
🎯 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 |
Problem
Kubernetes label and annotation keys routinely contain
/(the prefix separator) and-— for exampleapp.kubernetes.io/nameorcom.example/job-count. However,ExtendedTemplate.idpatterninsrc/robusta/utils/parsing.pyonly allows[_a-z0-9.], so a placeholder like:never matches and is left verbatim in the rendered output of
format_event_templated_string(used bycreate_finding,customise_finding,kubectl_command,foreign_logs_enricher,warning_events_report, krr args, …). This makes it impossible to reference most real-world label/annotation keys, since any key with a prefix or a hyphen is unmatchable.Solution
Extend only the braced form (
${...}) viastring.Template'sbraceidpatternto additionally allow/and-:The unbraced
idpatternis intentionally left untouched so existing templates like$name-suffix(where-suffixis literal text after the variable) keep their current behavior. This is fully backwards compatible: braced placeholders that matched before still match and resolve identically; the only new behavior is that previously-unmatchable keys now resolve.Testing
Added
tests/test_parsing.pycoveringformat_event_templated_string: subject fields (braced and unbraced), label/annotation lookups with plain and prefixed keys (${labels.app.kubernetes.io/name},${annotations.com.example/job-count}),<missing>fallback,$$escaping, and the unchanged$name-suffixunbraced behavior. The new slash/hyphen cases fail without the fix and pass with it; all 9 cases pass.🤖 Generated with Claude Code