feat(migration): add oak index (oakIndex) pattern support - #190
Conversation
Adds the oakIndex pattern to the migration skill for handling Oak index BPA findings (index.rule.violation, standard.index.modification) via the Adobe aem-cs-source-migration-index-converter tool. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
@Himanich @mandeep294 - what is your take in this PR - should we attempt to include the main logic in the code-assessment skill and only leave the BPA parsing here or is it fine as it is? |
| - `wkndTerminationDate` custom index without `-custom-` suffix (`index.rule.violation`) | ||
|
|
||
| Expected after running this skill: | ||
| - `damAssetLucene` → `<ootb-name-on-target-cloud-services>-<version>-custom-1` — the tool determines the exact name from the bundled Cloud Services baseline XML. With `aemVersion: Cloud_Services` and current tool version (0.2.3) this produces `damAssetStateIndex-3-custom-1`. The [reference branch `code/oid`](https://github.com/adobe/aem-guides-wknd-legacy/tree/code/oid) (created 2021) shows `damAssetLucene-6-custom-1` because that was the OOTB name at that time — both are correct for their respective baseline versions. The content is the full merged OOTB definition plus the customer's delta properties. |
There was a problem hiding this comment.
Should this be ootb-name-on-target-cloud-services → <ootb-name-on-target-cloud-services>-<version>-custom-1
|
i think we should we start migrating to "simplified index management" way of index creation? And instead of migrating skill why not we make it generic. where we look at index definition we are migrating to and create index version accordingly. |
| > Results should be reviewed carefully before use in production. | ||
| > Report issues at https://github.com/adobe/skills/issues | ||
|
|
||
| Rewrites legacy `_oak_index/*.xml` definitions to AEM as a Cloud Service compatible Oak index definitions by invoking Adobe's official **`@adobe/aem-cs-source-migration-index-converter`** CLI tool. Covers BPA subtypes `index.rule.violation` and `standard.index.modification` (category **OID**). |
There was a problem hiding this comment.
Do we also cover index checks e.g. index-definition nodetype is oak:indexDefiniton.
The datatype must not be incompatible in both index definitions on non-Cs and CS indexes etc.
3 participants
Adds the oakIndex pattern to the migration skill for handling Oak index BPA findings (index.rule.violation, standard.index.modification) via the Adobe aem-cs-source-migration-index-converter tool.
Description
Related Issue
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist: