From 0c616e6dde5efc1c84e211ac06d72e76482a5438 Mon Sep 17 00:00:00 2001 From: Kastriot Salihu Date: Tue, 16 Jun 2026 18:06:55 +0200 Subject: [PATCH 1/4] SP-925: Add PLATFORM_SERVICE validation layer to config validate Add PLATFORM_SERVICE as an accepted value of the --layers option on both 'config package validate' and the deprecated 'config validate', and document the new layer in the config command guide. Findings flow through the existing text report and --json output unchanged. Adds spec coverage for the request body, the text report, and the JSON report for the new layer. Includes-AI-Code: true Co-authored-by: Cursor --- docs/user-guide/config-commands.md | 11 ++- .../configuration-management/module.ts | 4 +- .../config-validate.spec.ts | 76 +++++++++++++++++++ 3 files changed, 85 insertions(+), 6 deletions(-) diff --git a/docs/user-guide/config-commands.md b/docs/user-guide/config-commands.md index 7b0cd599..e59f8fc5 100644 --- a/docs/user-guide/config-commands.md +++ b/docs/user-guide/config-commands.md @@ -204,17 +204,20 @@ The `--layers` option selects which validation layers to run. Multiple layers ca | `SCHEMA` | Asset-schema conformance of each node's `configuration` field — required properties, enum values, type checks, conditional schemas. | Asset registry | | `BUSINESS` | Asset-type-specific business rules — for `SEMANTIC_MODEL`, e.g. PQL parsing, data-model availability, KPI uniqueness. Rules live in the owning asset service. | Owning asset service (e.g. `cloud-semantic-layer` for Knowledge Models) | | `PACKAGE_SETTINGS` | Package-level configuration rules — package dependencies, package variable definitions, variable assignments such as Studio data models, and flavor-specific package settings for Studio/OCDM packages. | Pacman plus flavor-specific services | +| `PLATFORM_SERVICE` | Platform-service-owned validation — each participating platform service checks the assets it owns against its live service (for example Semantic Layer "list-problems" checks), surfacing platform-level problems that only the running service can detect. Which services take part, and how their findings map to severities, is declared by platform-service descriptors. | Owning platform services (e.g. `cloud-semantic-layer`), coordinated by Pacman | -Currently `SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are the layers accepted by the Pacman API. Other values are rejected with a `400 layers.unsupported` error. +`SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are accepted by the Pacman API today. `PLATFORM_SERVICE` is the newest layer and is only accepted once platform-service validation is enabled on the validate endpoint. Any value the endpoint does not (yet) support is rejected with a `400 layers.unsupported` error. To run all layers: ```bash -content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS +content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE ``` Use `PACKAGE_SETTINGS` when you need to verify that the package's own settings are usable in the destination team before continuing authoring or import work. It reports issues such as missing dependency versions, duplicate dependency or variable keys, blank variable keys/types, missing Studio data model assignments, and OCDM package-settings problems when the corresponding backend validation is enabled. +Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so new services can join the layer without CLI changes. Because it runs against the owning services, `PLATFORM_SERVICE` is only accepted once platform-service validation is enabled on the validate endpoint; until then the request is rejected with `400 layers.unsupported`. + ### Validate Specific Nodes By default, every node in the package's staging version is validated. To restrict the scope to a subset of nodes, use `--nodeKeys`: @@ -228,7 +231,7 @@ content-cli config package validate --packageKey --nodeKeys node-ke Use `--json` to write the full validation report to a JSON file in the current working directory instead of printing it to the console: ```bash -content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS --json +content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE --json ``` The filename is printed on success: @@ -248,7 +251,7 @@ interface ValidationReport { } interface ValidationResult { - layer: "SCHEMA" | "BUSINESS" | "PACKAGE_SETTINGS"; + layer: "SCHEMA" | "BUSINESS" | "PACKAGE_SETTINGS" | "PLATFORM_SERVICE"; severity: "ERROR" | "WARNING" | "INFO"; nodeKey: string; assetType: string; diff --git a/src/commands/configuration-management/module.ts b/src/commands/configuration-management/module.ts index 2d599b29..d2dc950c 100644 --- a/src/commands/configuration-management/module.ts +++ b/src/commands/configuration-management/module.ts @@ -84,7 +84,7 @@ class Module extends IModule { .requiredOption("--packageKey ", "Key of the package to validate") .option( "--layers ", - "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS). Defaults to SCHEMA.", + "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PLATFORM_SERVICE (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE). Defaults to SCHEMA.", ["SCHEMA"] ) .option("--nodeKeys ", "Specific node keys to validate (default: all nodes)") @@ -103,7 +103,7 @@ class Module extends IModule { .requiredOption("--packageKey ", "Key of the package to validate") .option( "--layers ", - "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS). Defaults to SCHEMA.", + "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PLATFORM_SERVICE (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE). Defaults to SCHEMA.", ["SCHEMA"] ) .option("--nodeKeys ", "Specific node keys to validate (default: all nodes)") diff --git a/tests/commands/configuration-management/config-validate.spec.ts b/tests/commands/configuration-management/config-validate.spec.ts index 0f35ea04..9cc6b4d4 100644 --- a/tests/commands/configuration-management/config-validate.spec.ts +++ b/tests/commands/configuration-management/config-validate.spec.ts @@ -104,4 +104,80 @@ describe("Config validate", () => { expect(allMessages).toContain("Validation result: VALID"); expect(allMessages).toContain("Errors: 0"); }) + + it("Should send PLATFORM_SERVICE layer in request body when combined with other layers", async () => { + const response: SchemaValidationResponse = { + packageKey: "my-package", + valid: true, + summary: { errors: 0, warnings: 0, info: 0 }, + results: [] + }; + + mockAxiosPost(VALIDATE_URL, response); + + await new PackageValidationService(testContext).validatePackage( + "my-package", + ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PLATFORM_SERVICE"], + null, + false + ); + + expect(mockedPostRequestBodyByUrl.get(VALIDATE_URL)).toEqual( + JSON.stringify({ layers: ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PLATFORM_SERVICE"] }) + ); + }) + + it("Should render PLATFORM_SERVICE findings in human-readable output", async () => { + const response: SchemaValidationResponse = { + packageKey: "my-package", + valid: false, + summary: { errors: 0, warnings: 1, info: 0 }, + results: [{ + layer: "PLATFORM_SERVICE", + severity: "WARNING", + nodeKey: "my-knowledge-model", + assetType: "SEMANTIC_MODEL", + path: "$.dataModel", + code: "DATA_MODEL_NOT_FOUND", + message: "Referenced data model is not available in the target team" + }] + }; + + mockAxiosPost(VALIDATE_URL, response); + + await new PackageValidationService(testContext).validatePackage("my-package", ["PLATFORM_SERVICE"], null, false); + + const allMessages = loggingTestTransport.logMessages.map(m => m.message).join("\n"); + expect(allMessages).toContain("Validation result: INVALID"); + expect(allMessages).toContain("Warnings: 1"); + expect(allMessages).toContain("my-knowledge-model (SEMANTIC_MODEL)"); + expect(allMessages).toContain("DATA_MODEL_NOT_FOUND"); + }) + + it("Should write PLATFORM_SERVICE findings to the JSON report when json flag is set", async () => { + const response: SchemaValidationResponse = { + packageKey: "my-package", + valid: false, + summary: { errors: 1, warnings: 0, info: 0 }, + results: [{ + layer: "PLATFORM_SERVICE", + severity: "ERROR", + nodeKey: "my-knowledge-model", + assetType: "SEMANTIC_MODEL", + path: "$.dataModel", + code: "DATA_MODEL_NOT_FOUND", + message: "Referenced data model is not available in the target team" + }] + }; + + mockAxiosPost(VALIDATE_URL, response); + + await new PackageValidationService(testContext).validatePackage("my-package", ["PLATFORM_SERVICE"], null, true); + + expect(mockWriteFileSync).toHaveBeenCalledWith( + expect.stringMatching(/config_validate_report_.+\.json$/), + JSON.stringify(response), + { encoding: "utf-8", mode: 0o600 } + ); + }) }) From 3d6ccb89f480719abcbfa0ff75fe03d40cc88beb Mon Sep 17 00:00:00 2001 From: Kastriot Salihu Date: Wed, 17 Jun 2026 17:09:38 +0200 Subject: [PATCH 2/4] SP-925: Reword PLATFORM_SERVICE docs to drop temporal phrasing Address review feedback on PR #381: describe the layer by its capability and its backend-enablement gating rather than by relative recency. Removes the "newest"/"today"/"(yet)"/"until then" wording from the validation-layers section of config-commands.md. Includes-AI-Code: true Co-authored-by: Cursor --- docs/user-guide/config-commands.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/config-commands.md b/docs/user-guide/config-commands.md index e59f8fc5..584b0251 100644 --- a/docs/user-guide/config-commands.md +++ b/docs/user-guide/config-commands.md @@ -206,7 +206,7 @@ The `--layers` option selects which validation layers to run. Multiple layers ca | `PACKAGE_SETTINGS` | Package-level configuration rules — package dependencies, package variable definitions, variable assignments such as Studio data models, and flavor-specific package settings for Studio/OCDM packages. | Pacman plus flavor-specific services | | `PLATFORM_SERVICE` | Platform-service-owned validation — each participating platform service checks the assets it owns against its live service (for example Semantic Layer "list-problems" checks), surfacing platform-level problems that only the running service can detect. Which services take part, and how their findings map to severities, is declared by platform-service descriptors. | Owning platform services (e.g. `cloud-semantic-layer`), coordinated by Pacman | -`SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are accepted by the Pacman API today. `PLATFORM_SERVICE` is the newest layer and is only accepted once platform-service validation is enabled on the validate endpoint. Any value the endpoint does not (yet) support is rejected with a `400 layers.unsupported` error. +`SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are accepted by the Pacman API. `PLATFORM_SERVICE` is accepted once platform-service validation is enabled on the validate endpoint. Any value the endpoint does not support is rejected with a `400 layers.unsupported` error. To run all layers: @@ -216,7 +216,7 @@ content-cli config package validate --packageKey --layers SCHEMA BU Use `PACKAGE_SETTINGS` when you need to verify that the package's own settings are usable in the destination team before continuing authoring or import work. It reports issues such as missing dependency versions, duplicate dependency or variable keys, blank variable keys/types, missing Studio data model assignments, and OCDM package-settings problems when the corresponding backend validation is enabled. -Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so new services can join the layer without CLI changes. Because it runs against the owning services, `PLATFORM_SERVICE` is only accepted once platform-service validation is enabled on the validate endpoint; until then the request is rejected with `400 layers.unsupported`. +Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so additional services can join the layer without CLI changes. Because it runs against the owning services, `PLATFORM_SERVICE` is only accepted once platform-service validation is enabled on the validate endpoint. ### Validate Specific Nodes From 8718bd871423c913592ddaa0dc67a5e75a5234bc Mon Sep 17 00:00:00 2001 From: Kastriot Salihu Date: Wed, 17 Jun 2026 17:28:09 +0200 Subject: [PATCH 3/4] SP-925: Document PLATFORM_SERVICE as a supported validate layer Drop the backend-enablement caveats and present PLATFORM_SERVICE alongside the other accepted layers, matching how SCHEMA/BUSINESS/PACKAGE_SETTINGS are documented. The Pacman validate endpoint change lands separately and this PR is merged once it does. Includes-AI-Code: true Co-authored-by: Cursor --- docs/user-guide/config-commands.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/user-guide/config-commands.md b/docs/user-guide/config-commands.md index 584b0251..4a32a067 100644 --- a/docs/user-guide/config-commands.md +++ b/docs/user-guide/config-commands.md @@ -206,7 +206,7 @@ The `--layers` option selects which validation layers to run. Multiple layers ca | `PACKAGE_SETTINGS` | Package-level configuration rules — package dependencies, package variable definitions, variable assignments such as Studio data models, and flavor-specific package settings for Studio/OCDM packages. | Pacman plus flavor-specific services | | `PLATFORM_SERVICE` | Platform-service-owned validation — each participating platform service checks the assets it owns against its live service (for example Semantic Layer "list-problems" checks), surfacing platform-level problems that only the running service can detect. Which services take part, and how their findings map to severities, is declared by platform-service descriptors. | Owning platform services (e.g. `cloud-semantic-layer`), coordinated by Pacman | -`SCHEMA`, `BUSINESS`, and `PACKAGE_SETTINGS` are accepted by the Pacman API. `PLATFORM_SERVICE` is accepted once platform-service validation is enabled on the validate endpoint. Any value the endpoint does not support is rejected with a `400 layers.unsupported` error. +`SCHEMA`, `BUSINESS`, `PACKAGE_SETTINGS`, and `PLATFORM_SERVICE` are the layers accepted by the Pacman API. Other values are rejected with a `400 layers.unsupported` error. To run all layers: @@ -216,7 +216,7 @@ content-cli config package validate --packageKey --layers SCHEMA BU Use `PACKAGE_SETTINGS` when you need to verify that the package's own settings are usable in the destination team before continuing authoring or import work. It reports issues such as missing dependency versions, duplicate dependency or variable keys, blank variable keys/types, missing Studio data model assignments, and OCDM package-settings problems when the corresponding backend validation is enabled. -Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so additional services can join the layer without CLI changes. Because it runs against the owning services, `PLATFORM_SERVICE` is only accepted once platform-service validation is enabled on the validate endpoint. +Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so additional services can join the layer without CLI changes. ### Validate Specific Nodes From e18554e5b289a51859f18ecee6bace9b50942061 Mon Sep 17 00:00:00 2001 From: Kastriot Salihu Date: Thu, 18 Jun 2026 14:48:48 +0200 Subject: [PATCH 4/4] SP-925: Replace PLATFORM_SERVICE with PIG_SEMANTICS and DATA_PIPELINES layers Platform-service validation is exposed as individual layer values rather than a single PLATFORM_SERVICE option. Update both validate commands' --layers help, the config-commands docs (layers table, accepted layers, examples, and the ValidationResult.layer union), and the specs to use PIG_SEMANTICS and DATA_PIPELINES. Includes-AI-Code: true Co-authored-by: Cursor --- docs/user-guide/config-commands.md | 13 +++++---- .../configuration-management/module.ts | 4 +-- .../config-validate.spec.ts | 28 +++++++++---------- 3 files changed, 23 insertions(+), 22 deletions(-) diff --git a/docs/user-guide/config-commands.md b/docs/user-guide/config-commands.md index 4a32a067..e0f257a8 100644 --- a/docs/user-guide/config-commands.md +++ b/docs/user-guide/config-commands.md @@ -204,19 +204,20 @@ The `--layers` option selects which validation layers to run. Multiple layers ca | `SCHEMA` | Asset-schema conformance of each node's `configuration` field — required properties, enum values, type checks, conditional schemas. | Asset registry | | `BUSINESS` | Asset-type-specific business rules — for `SEMANTIC_MODEL`, e.g. PQL parsing, data-model availability, KPI uniqueness. Rules live in the owning asset service. | Owning asset service (e.g. `cloud-semantic-layer` for Knowledge Models) | | `PACKAGE_SETTINGS` | Package-level configuration rules — package dependencies, package variable definitions, variable assignments such as Studio data models, and flavor-specific package settings for Studio/OCDM packages. | Pacman plus flavor-specific services | -| `PLATFORM_SERVICE` | Platform-service-owned validation — each participating platform service checks the assets it owns against its live service (for example Semantic Layer "list-problems" checks), surfacing platform-level problems that only the running service can detect. Which services take part, and how their findings map to severities, is declared by platform-service descriptors. | Owning platform services (e.g. `cloud-semantic-layer`), coordinated by Pacman | +| `PIG_SEMANTICS` | Semantic-model validation delegated to the Process Intelligence Graph semantic-layer runtime (PIG-SL), surfacing the `list-problems` findings the live service reports for Knowledge Models. | Semantic layer (`cloud-semantic-layer`) | +| `DATA_PIPELINES` | Validation delegated to the data-pipeline platform service for the package's data-integration assets. | Data pipeline service | -`SCHEMA`, `BUSINESS`, `PACKAGE_SETTINGS`, and `PLATFORM_SERVICE` are the layers accepted by the Pacman API. Other values are rejected with a `400 layers.unsupported` error. +`SCHEMA`, `BUSINESS`, `PACKAGE_SETTINGS`, `PIG_SEMANTICS`, and `DATA_PIPELINES` are the layers accepted by the Pacman API. Other values are rejected with a `400 layers.unsupported` error. To run all layers: ```bash -content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE +content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PIG_SEMANTICS DATA_PIPELINES ``` Use `PACKAGE_SETTINGS` when you need to verify that the package's own settings are usable in the destination team before continuing authoring or import work. It reports issues such as missing dependency versions, duplicate dependency or variable keys, blank variable keys/types, missing Studio data model assignments, and OCDM package-settings problems when the corresponding backend validation is enabled. -Use `PLATFORM_SERVICE` to additionally validate the package against the live platform services that own its assets — for example Semantic Layer problem checks for Knowledge Models. The set of services that take part, and how their findings map to severities, is declared by platform-service descriptors, so additional services can join the layer without CLI changes. +Use `PIG_SEMANTICS` and `DATA_PIPELINES` to additionally validate the package against the live platform services that own its assets: `PIG_SEMANTICS` runs the Process Intelligence Graph semantic-layer checks (for example for Knowledge Models) and `DATA_PIPELINES` runs the data-pipeline service checks for the package's data-integration assets. Both delegate validation to the owning service rather than running in-process; which services take part, and how their findings map to severities, is declared by platform-service descriptors. ### Validate Specific Nodes @@ -231,7 +232,7 @@ content-cli config package validate --packageKey --nodeKeys node-ke Use `--json` to write the full validation report to a JSON file in the current working directory instead of printing it to the console: ```bash -content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE --json +content-cli config package validate --packageKey --layers SCHEMA BUSINESS PACKAGE_SETTINGS PIG_SEMANTICS DATA_PIPELINES --json ``` The filename is printed on success: @@ -251,7 +252,7 @@ interface ValidationReport { } interface ValidationResult { - layer: "SCHEMA" | "BUSINESS" | "PACKAGE_SETTINGS" | "PLATFORM_SERVICE"; + layer: "SCHEMA" | "BUSINESS" | "PACKAGE_SETTINGS" | "PIG_SEMANTICS" | "DATA_PIPELINES"; severity: "ERROR" | "WARNING" | "INFO"; nodeKey: string; assetType: string; diff --git a/src/commands/configuration-management/module.ts b/src/commands/configuration-management/module.ts index d2dc950c..842bc4e0 100644 --- a/src/commands/configuration-management/module.ts +++ b/src/commands/configuration-management/module.ts @@ -84,7 +84,7 @@ class Module extends IModule { .requiredOption("--packageKey ", "Key of the package to validate") .option( "--layers ", - "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PLATFORM_SERVICE (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE). Defaults to SCHEMA.", + "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PIG_SEMANTICS, DATA_PIPELINES (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PIG_SEMANTICS DATA_PIPELINES). Defaults to SCHEMA.", ["SCHEMA"] ) .option("--nodeKeys ", "Specific node keys to validate (default: all nodes)") @@ -103,7 +103,7 @@ class Module extends IModule { .requiredOption("--packageKey ", "Key of the package to validate") .option( "--layers ", - "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PLATFORM_SERVICE (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PLATFORM_SERVICE). Defaults to SCHEMA.", + "Validation layers to run. Allowed values: SCHEMA, BUSINESS, PACKAGE_SETTINGS, PIG_SEMANTICS, DATA_PIPELINES (can be combined, e.g. --layers SCHEMA BUSINESS PACKAGE_SETTINGS PIG_SEMANTICS DATA_PIPELINES). Defaults to SCHEMA.", ["SCHEMA"] ) .option("--nodeKeys ", "Specific node keys to validate (default: all nodes)") diff --git a/tests/commands/configuration-management/config-validate.spec.ts b/tests/commands/configuration-management/config-validate.spec.ts index 9cc6b4d4..bf03c918 100644 --- a/tests/commands/configuration-management/config-validate.spec.ts +++ b/tests/commands/configuration-management/config-validate.spec.ts @@ -105,7 +105,7 @@ describe("Config validate", () => { expect(allMessages).toContain("Errors: 0"); }) - it("Should send PLATFORM_SERVICE layer in request body when combined with other layers", async () => { + it("Should send PIG_SEMANTICS and DATA_PIPELINES layers in request body when combined with other layers", async () => { const response: SchemaValidationResponse = { packageKey: "my-package", valid: true, @@ -117,23 +117,23 @@ describe("Config validate", () => { await new PackageValidationService(testContext).validatePackage( "my-package", - ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PLATFORM_SERVICE"], + ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PIG_SEMANTICS", "DATA_PIPELINES"], null, false ); expect(mockedPostRequestBodyByUrl.get(VALIDATE_URL)).toEqual( - JSON.stringify({ layers: ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PLATFORM_SERVICE"] }) + JSON.stringify({ layers: ["SCHEMA", "BUSINESS", "PACKAGE_SETTINGS", "PIG_SEMANTICS", "DATA_PIPELINES"] }) ); }) - it("Should render PLATFORM_SERVICE findings in human-readable output", async () => { + it("Should render PIG_SEMANTICS findings in human-readable output", async () => { const response: SchemaValidationResponse = { packageKey: "my-package", valid: false, summary: { errors: 0, warnings: 1, info: 0 }, results: [{ - layer: "PLATFORM_SERVICE", + layer: "PIG_SEMANTICS", severity: "WARNING", nodeKey: "my-knowledge-model", assetType: "SEMANTIC_MODEL", @@ -145,7 +145,7 @@ describe("Config validate", () => { mockAxiosPost(VALIDATE_URL, response); - await new PackageValidationService(testContext).validatePackage("my-package", ["PLATFORM_SERVICE"], null, false); + await new PackageValidationService(testContext).validatePackage("my-package", ["PIG_SEMANTICS"], null, false); const allMessages = loggingTestTransport.logMessages.map(m => m.message).join("\n"); expect(allMessages).toContain("Validation result: INVALID"); @@ -154,25 +154,25 @@ describe("Config validate", () => { expect(allMessages).toContain("DATA_MODEL_NOT_FOUND"); }) - it("Should write PLATFORM_SERVICE findings to the JSON report when json flag is set", async () => { + it("Should write DATA_PIPELINES findings to the JSON report when json flag is set", async () => { const response: SchemaValidationResponse = { packageKey: "my-package", valid: false, summary: { errors: 1, warnings: 0, info: 0 }, results: [{ - layer: "PLATFORM_SERVICE", + layer: "DATA_PIPELINES", severity: "ERROR", - nodeKey: "my-knowledge-model", - assetType: "SEMANTIC_MODEL", - path: "$.dataModel", - code: "DATA_MODEL_NOT_FOUND", - message: "Referenced data model is not available in the target team" + nodeKey: "my-data-pool", + assetType: "DATA_POOL", + path: "$.connection", + code: "CONNECTION_NOT_FOUND", + message: "Referenced connection is not available in the target team" }] }; mockAxiosPost(VALIDATE_URL, response); - await new PackageValidationService(testContext).validatePackage("my-package", ["PLATFORM_SERVICE"], null, true); + await new PackageValidationService(testContext).validatePackage("my-package", ["DATA_PIPELINES"], null, true); expect(mockWriteFileSync).toHaveBeenCalledWith( expect.stringMatching(/config_validate_report_.+\.json$/),