[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version #201301
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maximpn
added
release_note:skip
|
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
|
Pinging @elastic/security-solution (Team: SecuritySolution) |
|
Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management) |
maximpn
changed the title
maximpn
force-pushed
the
unlock-prebuilt-rule-upgrade-with-missing-base-version
branch
from
0c5eff1 to
c22758b
Compare
xcrzx
reviewed
Nov 22, 2024
| diff_outcome: hasBaseVersion | ||
| ? ThreeWayDiffOutcome.StockValueCanUpdate | ||
| : ThreeWayDiffOutcome.MissingBaseCanUpdate, | ||
| has_update: false, |
There was a problem hiding this comment.
Let's set has_update to true when there's an update to account for a situation when a version is bumped without any other content changes.
Comment on lines
40
to
42
| diff_outcome: hasBaseVersion | ||
| ? ThreeWayDiffOutcome.StockValueCanUpdate | ||
| : ThreeWayDiffOutcome.MissingBaseCanUpdate, |
There was a problem hiding this comment.
We also need to handle a situation when there's no update for proper diffing without a version bump. I.e, the case when a rule is edited locally rather than compared to a remote version.
There was a problem hiding this comment.
I applied determineDiffOutcome() it looks like a good fit here.
maximpn
force-pushed
the
unlock-prebuilt-rule-upgrade-with-missing-base-version
branch
2 times, most recently
from
26a3f57 to
f7ac96b
Compare
banderror
added
v8.17.0
bug
I would keep |
maximpn
force-pushed
the
unlock-prebuilt-rule-upgrade-with-missing-base-version
branch
from
f7ac96b to
7ec1b39
Compare
|
Me and @xcrzx discussed both options before I came up with the implementation
Both options have pros and cons but the first one looks more consistent. |
xcrzx
approved these changes
Nov 25, 2024
There was a problem hiding this comment.
Tested the fix locally, the rule upgrade flow now works without issues. Thanks for the fix, @maximpn!
- Tested rue upgrade with missing base version
- Rule upgrade with base version
- Tested rule editing that doesn't include rule version bump
|
Starting backport for target branches: 8.16, 8.17, 8.x |
💚 Build Succeeded
Metrics [docs]
History
cc @maximpn |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 25, 2024
…ules with missing base version (elastic#201301) **Resolves: elastic#200904 ## Summary This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version. ## Details Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade. A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it. The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version. (cherry picked from commit dea9312)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 25, 2024
…ules with missing base version (elastic#201301) **Resolves: elastic#200904 ## Summary This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version. ## Details Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade. A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it. The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version. (cherry picked from commit dea9312)
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Nov 25, 2024
…ules with missing base version (elastic#201301) **Resolves: elastic#200904 ## Summary This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version. ## Details Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade. A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it. The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version. (cherry picked from commit dea9312)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
maximpn
deleted the
unlock-prebuilt-rule-upgrade-with-missing-base-version
branch
kibanamachine
added a commit
that referenced
this pull request
Nov 25, 2024
…w for rules with missing base version (#201301) (#201656) # Backport This will backport the following commits from `main` to `8.17`: - [[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)](#201301) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Maxim Palenov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-25T17:12:35Z","message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","impact:high","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version","number":201301,"url":"https://github.com/elastic/kibana/pull/201301","mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201301","number":201301,"mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Maxim Palenov <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Nov 25, 2024
…w for rules with missing base version (#201301) (#201655) # Backport This will backport the following commits from `main` to `8.16`: - [[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)](#201301) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Maxim Palenov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-25T17:12:35Z","message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","impact:high","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version","number":201301,"url":"https://github.com/elastic/kibana/pull/201301","mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201301","number":201301,"mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Maxim Palenov <[email protected]>
kibanamachine
added a commit
that referenced
this pull request
Nov 25, 2024
… for rules with missing base version (#201301) (#201657) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)](#201301) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Maxim Palenov","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-25T17:12:35Z","message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","impact:high","v9.0.0","Team:Detections and Resp","Team: SecuritySolution","Team:Detection Rule Management","Feature:Prebuilt Detection Rules","backport:version","v8.17.0","v8.18.0","v8.16.2"],"title":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version","number":201301,"url":"https://github.com/elastic/kibana/pull/201301","mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/201301","number":201301,"mergeCommit":{"message":"[Security Solution] Unlock Prebuil Rules Customization workflow for rules with missing base version (#201301)\n\n**Resolves: https://github.com/elastic/kibana/issues/200904**\r\n\r\n## Summary\r\n\r\nThis PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.\r\n\r\n## Details\r\n\r\nEach Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.\r\n\r\nA generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it.\r\n\r\nThe fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.","sha":"dea9312246554c6af0ce148e2ec967bb5f9cca8a"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Maxim Palenov <[email protected]>
paulinashakirova
pushed a commit
to paulinashakirova/kibana
that referenced
this pull request
Nov 26, 2024
…ules with missing base version (elastic#201301) **Resolves: elastic#200904 ## Summary This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version. ## Details Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade. A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it. The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.
CAWilson94
pushed a commit
to CAWilson94/kibana
that referenced
this pull request
Dec 12, 2024
…ules with missing base version (elastic#201301) **Resolves: elastic#200904 ## Summary This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version. ## Details Each Prebuilt Rule update contains `version` diff. `version` is a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade. A generic `numberDiffAlgorithm` algorithm was used for `version` field. It produces a `SOLVABLE` conflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In case `version` field got a conflict user had no possibility to resolve it. The fix adds a new `forceTargetVersionDiffAlgorithm` diff algorithm applied only for `version` field. It produces a non-conflict diff all the time even when base version is missing. The reason behind is that `version` always gets target rule's version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves: #200904
Summary
This PR unlocks Prebuilt Rules Customization workflow for rules with missing base version.
Details
Each Prebuilt Rule update contains
versiondiff.versionis a special non-customizable field we use to track prebuilt rule version. It always gets target rule version's value after rule upgrade.A generic
numberDiffAlgorithmalgorithm was used forversionfield. It produces aSOLVABLEconflict when rule's base version is missing. It blocked the workflow in UI. We check the number of field with conflicts versus resolved conflicts to decide when a rule is ready for upgrade. In caseversionfield got a conflict user had no possibility to resolve it.The fix adds a new
forceTargetVersionDiffAlgorithmdiff algorithm applied only forversionfield. It produces a non-conflict diff all the time even when base version is missing. The reason behind is thatversionalways gets target rule's version.