chore: add policy opa crud#1096
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR introduces a new Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 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. Review rate limit: 0/1 reviews remaining, refill in 15 minutes and 23 seconds.Comment |
There was a problem hiding this comment.
Pull request overview
Adds support for a new policy rule type backed by OPA/Rego (“planValidationOpa”) across the API surface, DB relations, generated OpenAPI types, and e2e coverage to enable CRUD of these rules on policies.
Changes:
- Extend policy rule CRUD to persist and return
planValidationOparules. - Update OpenAPI schemas + generated TS types to include
PlanValidationOpaRule. - Add e2e coverage for creating policies with
planValidationOpa(with/without description).
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/workspace-engine-sdk/src/schema.ts | Updates generated SDK types with plan validation-related schemas and adds planValidationOpa to policy rule typing. |
| packages/db/src/schema/policy.ts | Adds a Drizzle relation from policy to policy_rule_plan_validation_opa. |
| e2e/tests/api/policies/policies.spec.ts | Adds e2e tests for policy creation/get with planValidationOpa rules. |
| e2e/api/schema.ts | Updates generated e2e OpenAPI typings for PlanValidationOpaRule and planValidationOpa fields. |
| apps/api/src/types/openapi.ts | Updates generated API OpenAPI typings for PlanValidationOpaRule and planValidationOpa fields. |
| apps/api/src/routes/v1/workspaces/policies.ts | Implements insert/delete/load/format support for planValidationOpa rules. |
| apps/api/openapi/schemas/policies.jsonnet | Adds PlanValidationOpaRule schema and references it from policy rule shapes. |
| apps/api/openapi/openapi.json | Updates the rendered OpenAPI document to include the new schema and fields. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| import { policyRulePlanValidationOpa } from "./deployment-plan.js"; | ||
| import { workspace } from "./workspace.js"; | ||
|
|
There was a problem hiding this comment.
Importing policyRulePlanValidationOpa from ./deployment-plan.js introduces a circular module dependency (deployment-plan -> policy for FK refs, and now policy -> deployment-plan for relations). This can result in partially-initialized exports at runtime and break Drizzle table/relations registration. Consider moving policyRulePlanValidationOpa (and its relations) into policy.ts, or extracting policy rule tables into a separate module that both files import to avoid cycles.
| PlanValidationOpaRule: { | ||
| type: 'object', | ||
| required: ['name', 'rego'], | ||
| properties: { | ||
| name: { | ||
| type: 'string', | ||
| description: 'Human-readable rule name; used in check output to identify which rule produced a violation.', | ||
| }, | ||
| description: { type: 'string' }, | ||
| rego: { | ||
| type: 'string', | ||
| description: 'Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).', | ||
| }, |
There was a problem hiding this comment.
The PR is marked as "fixes #1090", but #1090’s spec calls for a planValidation rule type (with a severity field) and also a validations read endpoint. This change set adds planValidationOpa without severity and doesn’t introduce the validations read route. Either update the PR description/issue linkage to reflect the narrower scope, or align the schema/API with the issue’s contract.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (1)
e2e/tests/api/policies/policies.spec.ts (1)
846-884: ⚡ Quick winCover the GET round-trip for the no-description case.
This test only checks the create response. Adding a GET assertion here would exercise the new serialization branch in
apps/api/src/routes/v1/workspaces/policies.tsthat omitsdescriptionwhen it is absent.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@e2e/tests/api/policies/policies.spec.ts` around lines 846 - 884, The test "should create a policy with planValidationOpa rule omitting description" only asserts the POST response; add a GET round-trip after creation to fetch the created policy and assert the persisted rules still omit the description. Specifically, after obtaining policyId in policies.spec.ts, call api.GET("/v1/workspaces/{workspaceId}/policies/{policyId}", { params: { path: { workspaceId: workspace.id, policyId } } }), then assert response.status is 200, that the returned rules length is 1, that rules[0].planValidationOpa matches { name: "always-deny", rego } and that rules[0].planValidationOpa?.description is undefined to exercise the serialization branch in the policies route.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@apps/api/openapi/openapi.json`:
- Around line 212-214: The OpenAPI schema property "planValidationOpa" is
misnamed and should be "planValidation" to match the API contract; update each
occurrence where the spec currently has the object key "planValidationOpa" to
use "planValidation" instead and keep the same referenced schema
(PlanValidationOpaRule) or rename that schema to PlanValidationRule if you
prefer clearer naming—ensure you update all three places mentioned (and
corresponding $ref targets if you rename the schema) so the components/schemas
and any consumers reference "planValidation" consistently.
- Around line 1594-1613: PlanValidationOpaRule is missing a severity field;
update the PlanValidationOpaRule schema by adding a new property named
"severity" (type: string) with a clear description such as "Severity level of
the rule (e.g., error, warning, info)" and include "severity" in the required
array if callers must always receive it (or leave out of required if optional),
so consumers and validation result reads can rely on rule severity.
In `@apps/api/openapi/schemas/policies.jsonnet`:
- Around line 134-147: PlanValidationOpaRule is missing the severity field so
clients cannot submit/read rule severity; add a new optional property "severity"
to PlanValidationOpaRule's properties (next to name/description/rego) with type
"string", a descriptive "description" explaining it conveys rule severity, and
an enum matching the request shape used elsewhere (e.g.
["error","warning","info"] or whatever the project convention is); if severity
must be mandatory per the linked issue, also add "severity" to the required
array alongside "name" and "rego".
In `@apps/api/src/routes/v1/workspaces/policies.ts`:
- Around line 135-142: The insertion for planValidationOpa omits the new
severity field so POST/PUT/GET/LIST lose that value; update the tx.insert into
schema.policyRulePlanValidationOpa (the branch checking rule.planValidationOpa)
to include severity: rule.planValidationOpa.severity in the .values(...) payload
and likewise update the symmetric insert block later (the other branch around
lines 278-286) to persist severity as well, and ensure any projection/formatting
code that builds the returned rule object includes the persisted severity
property from the policyRulePlanValidationOpa record.
In `@apps/api/src/types/openapi.ts`:
- Line 1202: The public type exposes planValidationOpa which diverges from the
required payload key planValidation; rename the property planValidationOpa to
planValidation in the OpenAPI types (update the property in the declaration
shown and the other occurrences currently using planValidationOpa) so it matches
the expected payload key, keeping the existing type
(components["schemas"]["PlanValidationOpaRule"]); if backward compatibility is
needed consider adding a deprecated optional alias property named
planValidationOpa that forwards to the new planValidation until callers are
migrated.
- Around line 1675-1681: PlanValidationOpaRule is missing the severity field
required by the PR; update the PlanValidationOpaRule type to include a severity
property (preferably a typed enum/union such as "error" | "warning" | "info" or
reference an existing Severity enum) and make it required if callers must supply
rules[].planValidation.severity, e.g. add severity: Severity | "error" |
"warning" | "info" to the PlanValidationOpaRule interface so API contracts and
clients can send/store the severity value.
In `@e2e/api/schema.ts`:
- Around line 1675-1681: The PlanValidationOpaRule type definition is missing
the severity field so clients cannot send or receive rule severity; update the
PlanValidationOpaRule interface/shape to include a severity property (e.g.,
severity: string or an enum type consistent with the OpenAPI contract) alongside
name, rego, and optional description, regenerate the OpenAPI/TS schema artifacts
if applicable, and ensure any consumers/validators (e.g., places referencing
PlanValidationOpaRule) are adjusted to handle the new severity field.
- Line 1202: Fix the misnamed rule key by renaming the property
planValidationOpa to planValidation everywhere it appears (e.g., the property
declaration planValidationOpa?: components["schemas"]["PlanValidationOpaRule"]
should become planValidation?: components["schemas"]["PlanValidationOpaRule"])
and update any references in arrays or types that expect rules[]. Also search
for and replace other usages of planValidationOpa (including in the schemas
referenced by rules[]) so the shape matches the API contract, then regenerate
the OpenAPI-derived types/clients to pick up the corrected key.
In `@packages/workspace-engine-sdk/src/schema.ts`:
- Around line 647-656: The PlanValidationResult type currently only exposes
ruleId; update the PlanValidationResult definition to include the joined rule
metadata returned by the validations read endpoint (e.g., add fields like
ruleName: string and ruleSeverity: string or the appropriate enum type from
components["schemas"] to mirror the API response), keep ruleId intact, and then
regenerate or re-run the OpenAPI-to-SDK generation so consumers can access the
joined rule name/severity alongside the existing fields referenced in
PlanValidationResult.
---
Nitpick comments:
In `@e2e/tests/api/policies/policies.spec.ts`:
- Around line 846-884: The test "should create a policy with planValidationOpa
rule omitting description" only asserts the POST response; add a GET round-trip
after creation to fetch the created policy and assert the persisted rules still
omit the description. Specifically, after obtaining policyId in
policies.spec.ts, call
api.GET("/v1/workspaces/{workspaceId}/policies/{policyId}", { params: { path: {
workspaceId: workspace.id, policyId } } }), then assert response.status is 200,
that the returned rules length is 1, that rules[0].planValidationOpa matches {
name: "always-deny", rego } and that rules[0].planValidationOpa?.description is
undefined to exercise the serialization branch in the policies route.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: a64f8551-6977-4ed0-b104-a53585d254c2
📒 Files selected for processing (8)
apps/api/openapi/openapi.jsonapps/api/openapi/schemas/policies.jsonnetapps/api/src/routes/v1/workspaces/policies.tsapps/api/src/types/openapi.tse2e/api/schema.tse2e/tests/api/policies/policies.spec.tspackages/db/src/schema/policy.tspackages/workspace-engine-sdk/src/schema.ts
| "planValidationOpa": { | ||
| "$ref": "#/components/schemas/PlanValidationOpaRule" | ||
| }, |
There was a problem hiding this comment.
Align the rule key with the requested API contract (planValidation).
The linked objective payload uses rules[].planValidation, but the spec only accepts planValidationOpa. That creates a contract mismatch for clients following the issue’s documented shape.
📌 Proposed OpenAPI alignment (apply in all three schemas)
- "planValidationOpa": {
+ "planValidation": {
"$ref": "#/components/schemas/PlanValidationOpaRule"
},Also applies to: 1691-1693, 2887-2889
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/openapi/openapi.json` around lines 212 - 214, The OpenAPI schema
property "planValidationOpa" is misnamed and should be "planValidation" to match
the API contract; update each occurrence where the spec currently has the object
key "planValidationOpa" to use "planValidation" instead and keep the same
referenced schema (PlanValidationOpaRule) or rename that schema to
PlanValidationRule if you prefer clearer naming—ensure you update all three
places mentioned (and corresponding $ref targets if you rename the schema) so
the components/schemas and any consumers reference "planValidation"
consistently.
| "PlanValidationOpaRule": { | ||
| "properties": { | ||
| "description": { | ||
| "type": "string" | ||
| }, | ||
| "name": { | ||
| "description": "Human-readable rule name; used in check output to identify which rule produced a violation.", | ||
| "type": "string" | ||
| }, | ||
| "rego": { | ||
| "description": "Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).", | ||
| "type": "string" | ||
| } | ||
| }, | ||
| "required": [ | ||
| "name", | ||
| "rego" | ||
| ], | ||
| "type": "object" | ||
| }, |
There was a problem hiding this comment.
Add severity to PlanValidationOpaRule (currently missing on Line 1595 schema fields).
The objective/example includes severity, and validation result reads are expected to include rule severity. Without this field in the schema, the contract is incomplete.
🛠️ Proposed schema fix
"PlanValidationOpaRule": {
"properties": {
"description": {
"type": "string"
},
"name": {
"description": "Human-readable rule name; used in check output to identify which rule produced a violation.",
"type": "string"
},
+ "severity": {
+ "description": "Severity used when reporting validation outcomes.",
+ "enum": [
+ "error",
+ "warning"
+ ],
+ "type": "string"
+ },
"rego": {
"description": "Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).",
"type": "string"
}
},
"required": [
"name",
+ "severity",
"rego"
],
"type": "object"
},📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "PlanValidationOpaRule": { | |
| "properties": { | |
| "description": { | |
| "type": "string" | |
| }, | |
| "name": { | |
| "description": "Human-readable rule name; used in check output to identify which rule produced a violation.", | |
| "type": "string" | |
| }, | |
| "rego": { | |
| "description": "Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).", | |
| "type": "string" | |
| } | |
| }, | |
| "required": [ | |
| "name", | |
| "rego" | |
| ], | |
| "type": "object" | |
| }, | |
| "PlanValidationOpaRule": { | |
| "properties": { | |
| "description": { | |
| "type": "string" | |
| }, | |
| "name": { | |
| "description": "Human-readable rule name; used in check output to identify which rule produced a violation.", | |
| "type": "string" | |
| }, | |
| "severity": { | |
| "description": "Severity used when reporting validation outcomes.", | |
| "enum": [ | |
| "error", | |
| "warning" | |
| ], | |
| "type": "string" | |
| }, | |
| "rego": { | |
| "description": "Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).", | |
| "type": "string" | |
| } | |
| }, | |
| "required": [ | |
| "name", | |
| "severity", | |
| "rego" | |
| ], | |
| "type": "object" | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/openapi/openapi.json` around lines 1594 - 1613,
PlanValidationOpaRule is missing a severity field; update the
PlanValidationOpaRule schema by adding a new property named "severity" (type:
string) with a clear description such as "Severity level of the rule (e.g.,
error, warning, info)" and include "severity" in the required array if callers
must always receive it (or leave out of required if optional), so consumers and
validation result reads can rely on rule severity.
| PlanValidationOpaRule: { | ||
| type: 'object', | ||
| required: ['name', 'rego'], | ||
| properties: { | ||
| name: { | ||
| type: 'string', | ||
| description: 'Human-readable rule name; used in check output to identify which rule produced a violation.', | ||
| }, | ||
| description: { type: 'string' }, | ||
| rego: { | ||
| type: 'string', | ||
| description: 'Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }).', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Add severity to the plan-validation rule schema.
The linked issue’s request shape includes severity, but PlanValidationOpaRule only accepts name, description, and rego. As-is, clients cannot submit or read rule severity through the policy endpoints.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/openapi/schemas/policies.jsonnet` around lines 134 - 147,
PlanValidationOpaRule is missing the severity field so clients cannot
submit/read rule severity; add a new optional property "severity" to
PlanValidationOpaRule's properties (next to name/description/rego) with type
"string", a descriptive "description" explaining it conveys rule severity, and
an enum matching the request shape used elsewhere (e.g.
["error","warning","info"] or whatever the project convention is); if severity
must be mandatory per the linked issue, also add "severity" to the required
array alongside "name" and "rego".
| if (rule.planValidationOpa != null) | ||
| await tx.insert(schema.policyRulePlanValidationOpa).values({ | ||
| id: ruleId, | ||
| policyId, | ||
| name: rule.planValidationOpa.name, | ||
| description: rule.planValidationOpa.description, | ||
| rego: rule.planValidationOpa.rego, | ||
| }); |
There was a problem hiding this comment.
Persist and return plan-validation severity.
This branch stores and formats name/description/rego only. Once severity is added to the contract, POST/PUT/GET/LIST will still drop it here, which breaks the requested rule shape and leaves the validations read endpoint without the joined severity data.
Also applies to: 278-286
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/routes/v1/workspaces/policies.ts` around lines 135 - 142, The
insertion for planValidationOpa omits the new severity field so
POST/PUT/GET/LIST lose that value; update the tx.insert into
schema.policyRulePlanValidationOpa (the branch checking rule.planValidationOpa)
to include severity: rule.planValidationOpa.severity in the .values(...) payload
and likewise update the symmetric insert block later (the other branch around
lines 278-286) to persist severity as well, and ensure any projection/formatting
code that builds the returned rule object includes the persisted severity
property from the policyRulePlanValidationOpa record.
| deploymentWindow?: components["schemas"]["DeploymentWindowRule"]; | ||
| environmentProgression?: components["schemas"]["EnvironmentProgressionRule"]; | ||
| gradualRollout?: components["schemas"]["GradualRolloutRule"]; | ||
| planValidationOpa?: components["schemas"]["PlanValidationOpaRule"]; |
There was a problem hiding this comment.
Rule key name diverges from the required payload shape (planValidation vs planValidationOpa).
The objective specifies rules[].planValidation, but these public request/response types expose only planValidationOpa. This creates a contract mismatch for API consumers following the issue spec.
Suggested key alignment
- planValidationOpa?: components["schemas"]["PlanValidationOpaRule"];
+ planValidation?: components["schemas"]["PlanValidationOpaRule"];Also applies to: 1706-1706, 2146-2146
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/types/openapi.ts` at line 1202, The public type exposes
planValidationOpa which diverges from the required payload key planValidation;
rename the property planValidationOpa to planValidation in the OpenAPI types
(update the property in the declaration shown and the other occurrences
currently using planValidationOpa) so it matches the expected payload key,
keeping the existing type (components["schemas"]["PlanValidationOpaRule"]); if
backward compatibility is needed consider adding a deprecated optional alias
property named planValidationOpa that forwards to the new planValidation until
callers are migrated.
| PlanValidationOpaRule: { | ||
| description?: string; | ||
| /** @description Human-readable rule name; used in check output to identify which rule produced a violation. */ | ||
| name: string; | ||
| /** @description Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */ | ||
| rego: string; | ||
| }; |
There was a problem hiding this comment.
Missing severity in PlanValidationOpaRule leaves the API contract incomplete.
The PR objective requires rules[].planValidation.severity, but this schema only exposes name, description, and rego. That blocks clients from sending/storing severity through typed API contracts.
Suggested contract update
PlanValidationOpaRule: {
description?: string;
/** `@description` Human-readable rule name; used in check output to identify which rule produced a violation. */
name: string;
/** `@description` Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */
rego: string;
+ /** `@description` Severity level for violations produced by this rule. */
+ severity: string;
};🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@apps/api/src/types/openapi.ts` around lines 1675 - 1681,
PlanValidationOpaRule is missing the severity field required by the PR; update
the PlanValidationOpaRule type to include a severity property (preferably a
typed enum/union such as "error" | "warning" | "info" or reference an existing
Severity enum) and make it required if callers must supply
rules[].planValidation.severity, e.g. add severity: Severity | "error" |
"warning" | "info" to the PlanValidationOpaRule interface so API contracts and
clients can send/store the severity value.
| deploymentWindow?: components["schemas"]["DeploymentWindowRule"]; | ||
| environmentProgression?: components["schemas"]["EnvironmentProgressionRule"]; | ||
| gradualRollout?: components["schemas"]["GradualRolloutRule"]; | ||
| planValidationOpa?: components["schemas"]["PlanValidationOpaRule"]; |
There was a problem hiding this comment.
Rule key name differs from expected API shape (planValidation vs planValidationOpa)
Lines 1202, 1706, and 2146 expose planValidationOpa, but the target contract specifies planValidation within rules[]. This naming mismatch can break consumers using the documented payload shape.
Suggested key alignment (source OpenAPI schema, then regenerate)
- planValidationOpa?: components["schemas"]["PlanValidationOpaRule"];
+ planValidation?: components["schemas"]["PlanValidationOpaRule"];Also applies to: 1706-1706, 2146-2146
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@e2e/api/schema.ts` at line 1202, Fix the misnamed rule key by renaming the
property planValidationOpa to planValidation everywhere it appears (e.g., the
property declaration planValidationOpa?:
components["schemas"]["PlanValidationOpaRule"] should become planValidation?:
components["schemas"]["PlanValidationOpaRule"]) and update any references in
arrays or types that expect rules[]. Also search for and replace other usages of
planValidationOpa (including in the schemas referenced by rules[]) so the shape
matches the API contract, then regenerate the OpenAPI-derived types/clients to
pick up the corrected key.
| PlanValidationOpaRule: { | ||
| description?: string; | ||
| /** @description Human-readable rule name; used in check output to identify which rule produced a violation. */ | ||
| name: string; | ||
| /** @description Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */ | ||
| rego: string; | ||
| }; |
There was a problem hiding this comment.
PlanValidationOpaRule is missing severity in the public contract
Line 1675–Line 1681 defines the new rule schema without severity, so clients can’t submit/read rule severity through typed payloads. This conflicts with the requested rule shape for plan validation.
Suggested contract shape (source OpenAPI schema, then regenerate)
PlanValidationOpaRule: {
description?: string;
/** `@description` Human-readable rule name; used in check output to identify which rule produced a violation. */
name: string;
+ /** `@description` Validation severity (for example: error, warning). */
+ severity: string;
/** `@description` Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */
rego: string;
};📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| PlanValidationOpaRule: { | |
| description?: string; | |
| /** @description Human-readable rule name; used in check output to identify which rule produced a violation. */ | |
| name: string; | |
| /** @description Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */ | |
| rego: string; | |
| }; | |
| PlanValidationOpaRule: { | |
| description?: string; | |
| /** `@description` Human-readable rule name; used in check output to identify which rule produced a violation. */ | |
| name: string; | |
| /** `@description` Validation severity (for example: error, warning). */ | |
| severity: string; | |
| /** `@description` Rego v1 source code. Must define a `deny` rule set following the Conftest convention (deny contains msg if { ... }). */ | |
| rego: string; | |
| }; |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@e2e/api/schema.ts` around lines 1675 - 1681, The PlanValidationOpaRule type
definition is missing the severity field so clients cannot send or receive rule
severity; update the PlanValidationOpaRule interface/shape to include a severity
property (e.g., severity: string or an enum type consistent with the OpenAPI
contract) alongside name, rego, and optional description, regenerate the
OpenAPI/TS schema artifacts if applicable, and ensure any consumers/validators
(e.g., places referencing PlanValidationOpaRule) are adjusted to handle the new
severity field.
| PlanValidationResult: { | ||
| /** Format: date-time */ | ||
| evaluatedAt: string; | ||
| id: string; | ||
| passed: boolean; | ||
| /** @description ID of the deployment_plan_target_result this validation was run against. */ | ||
| resultId: string; | ||
| /** @description Polymorphic rule id. Resolves to a specific rule type (e.g. PlanValidationOpaRule) known by the writing controller. */ | ||
| ruleId: string; | ||
| violations: components["schemas"]["PlanValidationViolation"][]; |
There was a problem hiding this comment.
Expose joined rule metadata in PlanValidationResult.
The new validations read endpoint is supposed to return results joined with rule name and severity, but this type still exposes only ruleId. SDK consumers will not be able to read the joined data until the source OpenAPI schema adds those fields and this file is regenerated.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/workspace-engine-sdk/src/schema.ts` around lines 647 - 656, The
PlanValidationResult type currently only exposes ruleId; update the
PlanValidationResult definition to include the joined rule metadata returned by
the validations read endpoint (e.g., add fields like ruleName: string and
ruleSeverity: string or the appropriate enum type from components["schemas"] to
mirror the API response), keep ruleId intact, and then regenerate or re-run the
OpenAPI-to-SDK generation so consumers can access the joined rule name/severity
alongside the existing fields referenced in PlanValidationResult.
fixes #1090
Summary by CodeRabbit