| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Signed-off-by: Jannik Hollenbach <jannik.hollenbach@iteratec.com>
Most of the text and structure here is generated based on the following prompt, then manually reviewed, just in case anybody wants to save time reading boilerplate :D ```prompt Please have a look at the current syntax for CascadingRules in the following files: documentation/docs/how-tos/scanning-networks.md documentation/docs/api/crds/cascading-rule.md Please write a ADR in the documentation/docs/architecture/09_architecture_decisions directory with a sugegsted move to switch out the custom `matches` object syntax of the CascadingRule with the Common Expression Language (CEL). The goal here would be make the CascadingRules more dynamic by allowing a wide range of expressions without us having to model the matcher syntax for everything ourself. describe the pros and cons of that approach try to follow the structure of existing ADRs in this repo ``` Signed-off-by: Jannik Hollenbach <jannik.hollenbach@iteratec.com>
✅ Deploy Preview for docs-securecodebox ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Sorry, something went wrong.
|
|
||
| To ensure backward compatibility and smooth migration: | ||
|
|
||
| 1. **Dual Support Period**: Support both the legacy `matches.anyOf` syntax and the new `matches.expression` syntax simultaneously for at least two major versions. |
There was a problem hiding this comment.
What happens if accidentally both is configured? Precedence of CEL + warning?
Sorry, something went wrong.
Signed-off-by: Jannik Hollenbach <jannik.hollenbach@iteratec.com>
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Description
See ADR :)
Checklist