fix: More deployment version refactor#371
Conversation
WalkthroughThis pull request refactors the way database schema entities are imported and referenced across the codebase. The changes consolidate multiple individual imports into a single namespace import ( Changes
Possibly related PRs
Poem
Tip ⚡🧪 Multi-step agentic review comment chat (experimental)
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
packages/db/src/schema/release.ts (1)
135-151: 🛠️ Refactor suggestionRename function to match new entity name.
Currently named
createReleasebut now referencesdeploymentVersion. Renaming is advisable to avoid confusion:-export const createRelease = createInsertSchema(deploymentVersion, { +export const createDeploymentVersion = createInsertSchema(deploymentVersion, {
🧹 Nitpick comments (12)
packages/api/src/router/resource-stats.ts (1)
104-110: Consider renaming the response property for API consistency.While the schema has been updated to use
DeploymentVersion, the API still returns areleaseproperty that is assigned the value fromrow.deployment_version. For consistency, consider renaming this todeploymentVersionin the returned object to match the schema changes..then((rows) => rows.map((row) => ({ ...row.job, deployment: row.deployment, - release: row.deployment_version, + deploymentVersion: row.deployment_version, })), );apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts (1)
45-47: Rename local variable for clarity
You have updated the table reference fromSCHEMA.releasetoSCHEMA.deploymentVersion, yet the local variable is still calledrelease. Consider renaming it (e.g.,deploymentVersion) to avoid confusion and maintain consistency.packages/job-dispatch/src/policies/release-dependency.ts (2)
20-25: Align property names with updated schema
The parametertrigger.releaseIdnow points toschema.deploymentVersion.id. Consider renaming it to something likedeploymentVersionIdto maintain clarity and consistency, especially since the table is nowdeploymentVersioninstead ofrelease.
110-118: Revisit remaining “release” references
You replaced references to the oldreleaseschema withdeploymentVersion, but there are still references likereleaseMatchesConditionandlatestJobSubquery.releaseId. If it now pertains to deployment versions, consider renaming these for consistency.packages/job-dispatch/src/policies/release-sequencing.ts (1)
88-88: Parameter naming inconsistency.The parameter is still named
release, but the type is nowschema.DeploymentVersion. Consider renaming the parameter for clarity.-const isReleaseLatestActiveForEnvironment = async (db: Tx, release: schema.DeploymentVersion, environmentId: string) => { +const isReleaseLatestActiveForEnvironment = async (db: Tx, deploymentVersion: schema.DeploymentVersion, environmentId: string) => {packages/api/src/router/job.ts (1)
66-66: Parameter name mismatch.This field is named
releasewhile referencingschema.DeploymentVersion. For clarity, rename it if possible.-release: schema.DeploymentVersion; +deploymentVersion: schema.DeploymentVersion;packages/api/src/router/deployment.ts (6)
45-46: Schema Update for Release Channel Update Input
UsingSCHEMA.updateReleaseChannelinside the input declaration standardizes the update validation. Double-check that this schema reflects all required fields and constraints as per the new data model.
87-98: Refactored List Procedure for Release Channels
The list query now selects fromSCHEMA.releaseChanneland, for calculating counts, fromSCHEMA.deploymentVersionusing the helperSCHEMA.releaseMatchesCondition. Please verify that the condition logic withinSCHEMA.releaseMatchesConditioncorrectly filters the records as intended.
388-395: Joining Deployment Versions in Distribution Query
The subsequent join withSCHEMA.deploymentVersionandSCHEMA.resourceintegrates the new naming by replacing previous release references. Consider if the returned key"release"(line 400) should be renamed for consistency with the deployment version terminology.
487-507: BySlug Query with Consolidated Schema Imports
The join operations amongSCHEMA.deployment,SCHEMA.system,SCHEMA.workspace, andSCHEMA.jobAgenthave been updated to use the schema namespace. Ensure that the aliasing (e.g., for job agent and any channel data) reflects the new data model semantics correctly.
514-523: Result Mapping in BySlug Query
The mapping of the query result (e.g., spreadingr[0].deployment, wrappingsystemdata, and collectingreleaseChannels) should be reviewed for consistency in naming. Consider whether the key"releaseChannels"accurately reflects the new deployment version context or if a rename (e.g.,"deploymentChannels") might improve clarity.
604-697: Complex Query in ByResourceId Procedure Using Schema References
This extensive query involves multiple joins acrossSCHEMA.resource,SCHEMA.environment,SCHEMA.deployment, and related tables. Please verify that:
- The use of the helper function
SCHEMA.resourceMatchesMetadataintegrates seamlessly with the rest of the query.- The ordering and limit constraints (e.g.,
.orderByand.limit(500)) deliver acceptable performance given the multiple joins and filtering conditions.
Consider adding inline comments or refactoring parts of the query into helper functions to improve readability and maintainability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (51)
apps/event-worker/src/job-dispatch/github.ts(3 hunks)apps/jobs/src/timeout-checker/index.ts(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/ReleaseBadgeList.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/deployment-resource-drawer/TableRow.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-drawer/OverviewContent.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/dependencies/DependencyDiagram.tsx(5 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/TriggerNode.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/deployments/resource-drawer/TableRow.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/release/ReleaseBadgeList.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/resources/ReleaseCell.tsx(3 hunks)apps/webservice/src/app/api/v1/config/route.ts(2 hunks)apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts(2 hunks)apps/webservice/src/app/api/v1/jobs/[jobId]/route.ts(1 hunks)apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts(1 hunks)apps/webservice/src/app/api/v1/releases/route.ts(1 hunks)packages/api/src/router/deployment-stats.ts(4 hunks)packages/api/src/router/deployment.ts(29 hunks)packages/api/src/router/environment-approval.ts(1 hunks)packages/api/src/router/environment-stats.ts(2 hunks)packages/api/src/router/job.ts(8 hunks)packages/api/src/router/release-deploy.ts(3 hunks)packages/api/src/router/release-metadata-keys.ts(3 hunks)packages/api/src/router/release.ts(16 hunks)packages/api/src/router/resource-stats.ts(2 hunks)packages/api/src/router/resources.ts(3 hunks)packages/auth/src/utils/rbac.ts(3 hunks)packages/db/src/schema/environment.ts(2 hunks)packages/db/src/schema/job.ts(3 hunks)packages/db/src/schema/release.ts(12 hunks)packages/job-dispatch/src/__test__/job-variables-deployment.test.ts(2 hunks)packages/job-dispatch/src/environment-creation.ts(1 hunks)packages/job-dispatch/src/environment-release-channel-update.ts(2 hunks)packages/job-dispatch/src/job-creation.ts(3 hunks)packages/job-dispatch/src/job-failure.ts(1 hunks)packages/job-dispatch/src/job-variables-deployment/utils.ts(1 hunks)packages/job-dispatch/src/policies/concurrency-policy.ts(5 hunks)packages/job-dispatch/src/policies/gradual-rollout.ts(2 hunks)packages/job-dispatch/src/policies/manual-approval.ts(2 hunks)packages/job-dispatch/src/policies/min-release-interval-policy.ts(4 hunks)packages/job-dispatch/src/policies/release-dependency.ts(2 hunks)packages/job-dispatch/src/policies/release-sequencing.ts(6 hunks)packages/job-dispatch/src/policies/release-string-check.ts(2 hunks)packages/job-dispatch/src/policies/success-rate-criteria-passing.ts(2 hunks)packages/job-dispatch/src/policy-create.ts(1 hunks)packages/job-dispatch/src/release-job-trigger.ts(5 hunks)packages/job-dispatch/src/release-sequencing.ts(1 hunks)packages/job-dispatch/src/resource/dispatch-resource.ts(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.{ts,tsx}`: **Note on Error Handling:** Avoid strict en...
**/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/v1/jobs/[jobId]/route.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsxpackages/job-dispatch/src/resource/dispatch-resource.tspackages/job-dispatch/src/release-sequencing.tsapps/webservice/src/app/api/v1/config/route.tsapps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.tsapps/jobs/src/timeout-checker/index.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsxpackages/job-dispatch/src/policies/concurrency-policy.tspackages/api/src/router/deployment-stats.tspackages/job-dispatch/src/policies/release-string-check.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/deployment-resource-drawer/TableRow.tsxpackages/db/src/schema/environment.tspackages/job-dispatch/src/policies/min-release-interval-policy.tspackages/job-dispatch/src/job-failure.tspackages/job-dispatch/src/policies/manual-approval.tspackages/api/src/router/resources.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/_components/deployments/resource-drawer/TableRow.tsxpackages/job-dispatch/src/policies/gradual-rollout.tsapps/webservice/src/app/api/v1/releases/route.tsapps/event-worker/src/job-dispatch/github.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsxapps/webservice/src/app/[workspaceSlug]/(app)/_components/ReleaseBadgeList.tsxpackages/job-dispatch/src/__test__/job-variables-deployment.test.tspackages/job-dispatch/src/policy-create.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/release-drawer/OverviewContent.tsxapps/webservice/src/app/api/v1/releases/[releaseId]/route.tspackages/api/src/router/environment-approval.tspackages/api/src/router/release-metadata-keys.tspackages/job-dispatch/src/environment-release-channel-update.tsapps/webservice/src/app/[workspaceSlug]/(app)/dependencies/DependencyDiagram.tsxapps/webservice/src/app/[workspaceSlug]/(appv2)/_components/release/ReleaseBadgeList.tsxapps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/TriggerNode.tsxpackages/job-dispatch/src/policies/success-rate-criteria-passing.tspackages/job-dispatch/src/environment-creation.tspackages/api/src/router/resource-stats.tspackages/job-dispatch/src/policies/release-dependency.tspackages/api/src/router/release-deploy.tspackages/auth/src/utils/rbac.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/_components/resources/ReleaseCell.tsxpackages/api/src/router/release.tspackages/db/src/schema/job.tsapps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsxpackages/api/src/router/environment-stats.tspackages/db/src/schema/release.tspackages/job-dispatch/src/job-creation.tspackages/job-dispatch/src/job-variables-deployment/utils.tspackages/job-dispatch/src/policies/release-sequencing.tspackages/api/src/router/job.tspackages/api/src/router/deployment.tspackages/job-dispatch/src/release-job-trigger.ts
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Typecheck
- GitHub Check: build (linux/amd64)
- GitHub Check: build (linux/amd64)
- GitHub Check: Lint
🔇 Additional comments (166)
apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsx (1)
27-27: Type update looks good!The change from
SCHEMA.ReleasetoSCHEMA.DeploymentVersionaligns with the broader schema refactoring across the codebase. The component continues to work correctly as it accesses the same properties (id, version, createdAt) which exist in both types.packages/job-dispatch/src/environment-creation.ts (1)
56-64: Schema references updated correctlyThe changes properly update all references from
SCHEMA.releasetoSCHEMA.deploymentVersionwhile maintaining the same query structure. The function continues to work with the same underlying data model, just with the renamed schema entity.packages/job-dispatch/src/resource/dispatch-resource.ts (1)
85-93: Schema references consistently updatedThe changes properly update all references from
SCHEMA.releasetoSCHEMA.deploymentVersionin the database query. This maintains consistency with the schema refactoring across the codebase while preserving the existing query logic.apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/release/ReleaseBadgeList.tsx (1)
7-7: Type definition correctly updatedThe property type update from
SCHEMA.Release[]toSCHEMA.DeploymentVersion[]aligns with the schema refactoring. The component still accesses the same properties (idandname), which exist in both types, ensuring the component functions correctly with the new type.packages/job-dispatch/src/environment-release-channel-update.ts (4)
74-77: Schema entity replacements look goodThe inner join has been correctly updated from using
SCHEMA.releasetoSCHEMA.deploymentVersion, maintaining the same relationship withSCHEMA.releaseJobTrigger.releaseId.
79-81: Deployment reference properly updatedThe condition has been correctly updated to reference
SCHEMA.deploymentVersion.deploymentIdinstead of the previousSCHEMA.release.deploymentId.
101-107: Data source correctly refactoredThe select query has been properly updated to use
SCHEMA.deploymentVersionas the data source instead ofSCHEMA.release.
110-111: Sort order maintained in new entityThe ordering has been properly updated to use
SCHEMA.deploymentVersion.createdAtmaintaining the same sort behavior after the schema entity change.packages/job-dispatch/src/release-job-trigger.ts (8)
11-11: Import refactoring looks goodThe migration from individual schema imports to a consolidated namespace import improves code organization.
78-88: References properly updated with namespaceAll entity references have been correctly updated to use the SCHEMA namespace, and
releasereferences have been replaced withdeploymentVersion.
91-103: Base query joins consistently updatedAll join conditions have been properly updated to use the SCHEMA namespace, maintaining the same relationship logic.
105-118: Release subquery properly refactoredThe method has been updated to reference
SCHEMA.deploymentVersionentities instead of release, maintaining the same functionality with the new schema structure.
122-136: Branch conditions properly updatedBoth conditional branches in the
_valuesmethod have been updated to use the new schema references, ensuring consistent behavior across code paths.
144-156: Resource query conditions updated correctlyAll conditions in the resource query have been updated to use the SCHEMA namespace, preserving the original query logic.
184-200: Release query properly refactoredThe joins and conditions have been correctly updated to use
SCHEMA.deploymentVersioninstead of release, maintaining the same relationships.
220-223: Insert operation updated consistentlyThe insert operation now correctly uses the SCHEMA namespace, maintaining the same functionality.
packages/job-dispatch/src/policy-create.ts (3)
6-6: Import refactoring looks goodThe migration from individual schema imports to a consolidated namespace import improves code organization.
12-38: Query structure properly refactoredThe selectDistinctOn, from clause, and all join conditions have been updated to use the SCHEMA namespace and replace release references with deploymentVersion, maintaining the same query logic.
42-50: Insert operation updated correctlyThe insert operation has been updated to use the SCHEMA namespace, and the mapping now correctly references
p.deployment_version.idinstead of release.apps/webservice/src/app/api/v1/jobs/[jobId]/route.ts (3)
84-87: Schema entity replacement looks goodThe left join has been correctly updated to use
schema.deploymentVersioninstead ofschema.release, maintaining the same relationship withschema.releaseJobTrigger.releaseId.
88-91: Deployment join condition properly updatedThe join condition has been correctly updated to reference
schema.deploymentVersion.deploymentIdinstead ofschema.release.deploymentId.
104-107: Release reference properly updatedThe conditional check and object creation now correctly use
row.deployment_versioninstead ofrow.release.packages/job-dispatch/src/job-variables-deployment/utils.ts (2)
24-28: LGTM: Consistent schema refactoringThe join has been correctly updated from
SCHEMA.releasetoSCHEMA.deploymentVersion, maintaining the same relationship between tables while aligning with the broader schema refactoring effort.
30-30: LGTM: Consistent where clause updateThe where clause has been properly updated to filter by
SCHEMA.deploymentVersion.idinstead ofSCHEMA.release.id, maintaining query functionality while following the schema refactoring pattern.apps/jobs/src/timeout-checker/index.ts (2)
12-13: LGTM: Consistent schema refactoring in join clauseThe join has been correctly updated from
SCHEMA.releasetoSCHEMA.deploymentVersion, maintaining the same query structure while aligning with the refactoring effort.
17-17: LGTM: Properly updated join conditionThe join condition has been correctly updated to use
SCHEMA.deploymentVersion.idinstead ofSCHEMA.release.id, maintaining the same relationship between tables in the query.apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/TriggerNode.tsx (1)
7-7: LGTM: Type definition updated consistentlyThe type definition has been properly updated from
SCHEMA.ReleasetoSCHEMA.DeploymentVersion, aligning with the broader schema refactoring across the codebase.apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsx (2)
1-1: LGTM: Import style updated to use namespaceImport updated to use the
SCHEMAnamespace, which is consistent with the refactoring pattern seen throughout the PR.
14-14: LGTM: Type definition updated consistentlyThe type definition has been properly updated to use
SCHEMA.EnvironmentandSCHEMA.DeploymentVersioninstead of direct imports, maintaining component functionality while aligning with the schema refactoring.packages/api/src/router/environment-approval.ts (2)
109-111: Entity reference updated correctlyThe inner join now correctly references
SCHEMA.deploymentVersioninstead ofSCHEMA.release, maintaining proper relationship between release job triggers and deployment versions.
115-115: Where clause condition updated properlyThe condition is correctly updated to check against
SCHEMA.deploymentVersion.idinstead ofSCHEMA.release.id, maintaining consistency with the schema refactoring.apps/webservice/src/app/api/v1/releases/route.ts (2)
56-63: Entity reference updated correctlyThe select query has been properly updated to use
schema.deploymentVersioninstead ofschema.release, with appropriate where clause conditions using the new schema entity.
65-82: Insert and conflict resolution properly refactoredThe insert operation and conflict resolution logic have been correctly updated to use
schema.deploymentVersioninstead ofschema.release, including proper target fields and conflict column sets.apps/webservice/src/app/api/v1/config/route.ts (2)
161-164: Left join updated correctlyThe left join has been appropriately updated to join with
schema.deploymentVersioninstead ofschema.release, maintaining the correct relationship with the deployment entity.
212-214: Insert target updated properlyThe insert operation now correctly targets
schema.deploymentVersioninstead ofschema.release, aligning with the schema refactoring across the codebase.packages/job-dispatch/src/policies/release-string-check.ts (2)
68-70: Query updated correctlyThe select query has been properly updated to use
schema.deploymentVersioninstead ofschema.release, with the appropriate where clause condition.
86-95: Matching release query updated properlyThe query to find matching releases now correctly references
schema.deploymentVersioninstead ofschema.release, ensuring consistency with the schema refactoring.apps/webservice/src/app/[workspaceSlug]/(app)/_components/ReleaseBadgeList.tsx (1)
7-7: Type change looks good.The change from
SCHEMA.Release[]toSCHEMA.DeploymentVersion[]aligns with the broader refactoring to standardize onDeploymentVersionacross the codebase. The component functionality remains unchanged since both types appear to have the requiredidandnameproperties used in the template.packages/api/src/router/resource-stats.ts (3)
79-83: Query schema references updated correctly.The changes from
SCHEMA.releasetoSCHEMA.deploymentVersionin theselectDistinctOnmethod andfromclause accurately reflect the schema migration. The join condition has also been properly updated to match the new entity names.
91-92: Join condition updated correctly.The inner join between deployment and deployment version tables has been properly updated to reflect the new schema structure.
100-103: Order by clause updated correctly.The
orderByclause now correctly references thedeploymentVersiontable instead of thereleasetable, maintaining the same sorting logic.packages/job-dispatch/src/release-sequencing.ts (4)
29-33: SQL subquery updated correctly.The schema references in the trigger subquery have been properly updated from
releasetodeploymentVersion, maintaining the same logical structure while reflecting the new schema design.
35-36: Join conditions properly refactored.The inner join expressions have been updated to use the new
deploymentVersionschema instead ofrelease, with appropriate relationship paths maintained.
43-45: Join conditions for job cancellation updated correctly.The join conditions in the jobs cancellation query have been properly updated to use the new schema entities.
50-52: Cancel conditions updated correctly.The conditions used to determine which jobs to cancel have been updated to reference the deployment version ID and creation time instead of release fields.
apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsx (3)
1-1: Import style standardized.The change to a namespace import for the schema types is consistent with the refactoring approach used throughout the codebase.
17-19: Type references updated correctly.The
PolicyNodePropstype definition has been properly updated to use theSCHEMAnamespace and to referenceDeploymentVersioninstead ofRelease. This ensures type safety while maintaining the same property name for backward compatibility.
1-186: Path naming inconsistency relative to component name.The component path contains "releases/[releaseId]" while the component now works with
DeploymentVersion. The URL structure might need to be updated in a future PR to reflect this schema change, or a justification added for keeping the old naming in the URL.This is just an observation - no immediate changes needed, but it might be worth documenting the reason for keeping "releases" in the URL path while using
DeploymentVersionin the code or planning for URL structure updates in a follow-up PR.packages/job-dispatch/src/job-failure.ts (2)
15-16: LGTM: Successfully updated join reference to deploymentVersionThe change correctly updates the inner join to reference the new
schema.deploymentVersionentity instead of the previousschema.releaseentity, aligning with the broader refactoring effort.
20-20: LGTM: Properly updated join conditionThe join condition is correctly updated to use
schema.deploymentVersion.deploymentIdinstead of the previousschema.release.deploymentId, maintaining the relationship integrity in the query.apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-drawer/OverviewContent.tsx (3)
3-3: LGTM: Added namespace import for schema typesGood change to use a namespace import for schema types, which is consistent with the refactoring approach seen across the codebase.
19-19: LGTM: Updated component prop typeCorrectly updated the
releaseprop type from directReleaseimport to use the namespacedSCHEMA.DeploymentVersion, maintaining type safety while adopting the new naming convention.
21-21: LGTM: Updated dependencies typeThe type for
dependenciesis properly updated to use the namespacedSCHEMA.ReleaseDependency[]type definition.packages/api/src/router/environment-stats.ts (3)
42-42: LGTM: Updated SQL rank calculationThe SQL query for rank calculation is correctly updated to use
SCHEMA.deploymentVersion.deploymentIdinstead of the previous release reference, maintaining the partitioning logic.
53-54: LGTM: Updated inner join to deploymentVersionSuccessfully replaced the inner join to
SCHEMA.releasewithSCHEMA.deploymentVersion, ensuring consistency with the updated data model.
58-58: LGTM: Updated join conditionThe join condition for the deployment table is properly updated to reference
SCHEMA.deploymentVersion.deploymentId.packages/job-dispatch/src/policies/min-release-interval-policy.ts (7)
24-25: LGTM: Updated field referencesCorrectly updated field references from
SCHEMA.releasetoSCHEMA.deploymentVersionin the select statement.
27-27: LGTM: Updated SQL rank calculationThe SQL partitioning expression is properly updated to reference
SCHEMA.deploymentVersion.deploymentIdandSCHEMA.deploymentVersion.createdAt.
31-31: LGTM: Updated from clauseThe
fromclause is correctly updated to select fromSCHEMA.deploymentVersioninstead ofSCHEMA.release.
44-47: LGTM: Updated equality conditionSuccessfully updated the equality condition to compare
SCHEMA.releaseJobTrigger.releaseIdwithSCHEMA.deploymentVersion.id.
66-69: LGTM: Updated second equality conditionProperly updated the second equality condition in the notExists clause to reference
SCHEMA.deploymentVersion.id.
100-100: LGTM: Updated from clause in second queryThe
fromclause in the second query is correctly updated to select fromSCHEMA.deploymentVersion.
103-103: LGTM: Updated id reference in where clauseSuccessfully updated the id reference in the where clause to use
SCHEMA.deploymentVersion.id.packages/job-dispatch/src/policies/manual-approval.ts (2)
24-25: Reference updated correctly to usedeploymentVersion.The schema reference has been properly updated from
releasetodeploymentVersion, maintaining the correct relationship withreleaseJobTrigger.releaseId.
38-41: Join condition correctly updated to usedeploymentVersion.id.The join condition has been properly updated to reference
schema.deploymentVersion.idinstead ofschema.release.id, maintaining the correct relationship withenvironmentPolicyApproval.releaseId.packages/db/src/schema/environment.ts (2)
26-26: Import statement correctly updated.The import has been properly updated from
releasetodeploymentVersionto align with the data model changes.
264-264: Foreign key reference properly updated.The foreign key reference has been correctly updated to reference
deploymentVersion.idinstead ofrelease.id, ensuring database integrity with the new data model.packages/api/src/router/resources.ts (5)
97-100:ROW_NUMBER()partitioning correctly updated.The
PARTITION BYclause in theROW_NUMBER()function has been properly updated to useschema.deploymentVersion.deploymentId, and the correspondingrankDeploymentIdvariable has been updated to match.
104-108: Source table and join condition correctly updated.The source table for the rank subquery has been properly updated from
schema.releasetoschema.deploymentVersion, and the join condition has been updated to maintain the correct relationship withreleaseJobTrigger.
120-122: Inner join correctly updated to usedeploymentVersion.The inner join has been properly updated to use
schema.deploymentVersionand the correct join condition withdeployment.id.
126-126: Join condition correctly updated.The join condition has been properly updated to reference
schema.deploymentVersion.idinstead ofschema.release.id.
137-140: Rank subquery join condition correctly updated.The condition for joining the
rankSubqueryhas been properly updated to compare withschema.deploymentVersion.deploymentIdinstead ofschema.release.deploymentId.packages/job-dispatch/src/job-creation.ts (6)
81-83: Inner join correctly updated to usedeploymentVersion.The inner join has been properly updated to connect
schema.releaseJobTrigger.releaseIdtoschema.deploymentVersion.idinstead ofschema.release.id.
86-87: Join condition correctly updated.The inner join condition has been properly updated to connect
schema.deploymentVersion.deploymentIdtoschema.deployment.idinstead ofschema.release.deploymentId.
106-110: Concurrency requirement condition correctly updated.The condition checking for concurrency requirements has been properly updated to compare
schema.deploymentVersion.deploymentIdwithtriggers.deployment_version.deploymentIdinstead ofschema.release.deploymentId.
120-121: Waiting condition correctly updated.The condition for checking if a job is waiting on another job to finish has been properly updated to compare
schema.deploymentVersion.idwithtriggers.deployment_version.idinstead ofschema.release.id.
127-129: Inner join correctly updated in affected queries.The inner join for affected release job triggers has been properly updated to connect
schema.releaseJobTrigger.releaseIdtoschema.deploymentVersion.idinstead ofschema.release.id.
132-133: Deployment join condition correctly updated.The inner join condition has been properly updated to connect
schema.deploymentVersion.deploymentIdtoschema.deployment.idinstead ofschema.release.deploymentId.apps/event-worker/src/job-dispatch/github.ts (3)
6-6: LGTM! Consolidated schema imports.This change is part of the broader refactoring to consolidate database schema imports into a single namespace import, which improves code organization.
21-25: Properly updated schema references in the query.The query now correctly uses the SCHEMA namespace for githubEntity and workspace entities.
84-91: Renamed entity from 'release' to 'deploymentVersion'.This change correctly updates the query to use deploymentVersion instead of release, aligning with the data model changes across the codebase.
packages/api/src/router/release-metadata-keys.ts (3)
5-5: LGTM! Consolidated schema imports.Importing all schema entities under a single namespace improves code organization and maintainability.
22-33: Correctly updated schema references in the 'bySystem' query.The query properly uses the SCHEMA namespace and references deploymentVersion instead of release, maintaining functionality while improving code clarity.
47-62: Correctly updated schema references in the 'byWorkspace' query.All entity references have been properly updated to use the SCHEMA namespace and deploymentVersion, consistent with the data model changes.
packages/auth/src/utils/rbac.ts (3)
15-15: Added deploymentVersion to imports.Correctly added deploymentVersion to the list of imported schema entities to support the refactoring.
97-102: Updated getReleaseScopes to use deploymentVersion.The function now correctly joins on deploymentVersion instead of release, aligning with the new data model.
359-364: Updated getJobScopes to use deploymentVersion.The join logic has been properly updated to reference deploymentVersion instead of release, maintaining the relationship between entities while reflecting the data model changes.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/deployment-resource-drawer/TableRow.tsx (2)
73-73: Updated type from Release to DeploymentVersion.The type of the release property in DropdownCellProps has been correctly updated to SCHEMA.DeploymentVersion, consistent with the entity name change.
87-87: Updated type from Release to DeploymentVersion.The type of the release property in ReleaseJobTriggerRowProps has been correctly updated to SCHEMA.DeploymentVersion, ensuring type consistency across the codebase.
apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/deployments/resource-drawer/TableRow.tsx (2)
73-73: Type reference updated to reflect schema change.The type for the
releaseproperty has been correctly updated fromSCHEMA.ReleasetoSCHEMA.DeploymentVersionto align with the broader schema refactoring.
87-87: Type reference updated to reflect schema change.The type for the
releaseproperty has been correctly updated fromSCHEMA.ReleasetoSCHEMA.DeploymentVersion, maintaining consistency with the schema refactoring across the codebase.apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (3)
8-8: Import refactored to use namespace pattern.The import has been updated to use a single namespace import for all schema entities, which simplifies imports and aligns with the broader refactoring approach.
24-48: Database query updated to use SCHEMA namespace and DeploymentVersion entity.The database query has been correctly updated to:
- Use the
SCHEMA.prefix for all entity references- Replace
releasewithdeploymentVersionin the join conditionsThis maintains consistency with the schema refactoring while preserving the original query logic.
51-59: Where clause updated to use SCHEMA namespace.The where clause conditions have been properly updated to use the
SCHEMA.prefix for all entity references, completing the refactoring of this database query.packages/job-dispatch/src/__test__/job-variables-deployment.test.ts (2)
72-72: Constant type updated to reflect schema change.The type for the
deployment_versionconstant has been correctly updated fromSCHEMA.ReleasetoSCHEMA.DeploymentVersion, aligning with the schema refactoring initiative.
107-107: Variable type updated for consistency.The type definition for the
deployment_versionproperty in thevariabletype has been updated toSCHEMA.DeploymentVersion, maintaining consistency with the schema changes throughout the codebase.packages/job-dispatch/src/policies/concurrency-policy.ts (5)
27-29: Join updated to use DeploymentVersion entity.The join has been updated to use
schema.deploymentVersioninstead ofschema.release, correctly implementing the schema change while preserving the join logic.
65-66: Updated field reference to use DeploymentVersion.The field reference for
deploymentIdnow correctly usesschema.deploymentVersion.deploymentId, consistent with the schema changes.
78-80: Join updated to use DeploymentVersion entity.Another join to
schema.releasehas been properly updated to useschema.deploymentVersion, maintaining consistency throughout the query.
91-95: Entity reference updated in filter condition.The reference to
schema.release.deploymentIdhas been changed toschema.deploymentVersion.deploymentIdin the filter conditions, correctly implementing the schema change.
104-107: Group by clause updated to use DeploymentVersion entity.The group by clause has been updated to use
schema.deploymentVersion.deploymentIdinstead ofschema.release.deploymentId, completing the consistent application of the schema change throughout this query.packages/api/src/router/deployment-stats.ts (4)
164-164: Confirm “inactive deployment” logic
ReplacingisNull(schema.release)withisNull(schema.deploymentVersion)changes how “inactive” deployments are determined. Double-check that this new condition correctly aligns with the updated data model's definition of inactivity.
187-192: Verify updated left join
References to theschema.deploymentVersiontable andeq(schema.releaseJobTrigger.releaseId, schema.deploymentVersion.id)should be consistent with the rest of the data model. Confirm that these joins and ID references match the intended rows.
245-250: Consistent join with deployment version
Switching fromschema.release.idtoschema.deploymentVersion.idand matching it toschema.releaseJobTrigger.releaseIdis a logical shift toward the new table. This change looks good to merge as part of the overall refactor.
300-305: Double-check filtering correctness
Filtering byeq(schema.deploymentVersion.deploymentId, deploymentId)refines results to the new schema. Verify that this correctly encloses all valid deployment versions and excludes extraneous data.packages/job-dispatch/src/policies/gradual-rollout.ts (2)
30-30: Type update looks good.The parameter type change from
schema.Releasetoschema.DeploymentVersionproperly reflects the revised data model being used across the codebase.
80-82: Join statement update looks good.The SQL join has been correctly updated to reference
schema.deploymentVersioninstead ofschema.release. This change is consistent with the broader refactoring effort to transition from Release to DeploymentVersion entities.packages/api/src/router/release-deploy.ts (4)
4-4: Import consolidation looks good.Good approach to consolidate multiple individual schema imports into a single namespace import. This makes imports more maintainable and consistent.
88-94: Schema references properly updated.All references to schema entities have been correctly updated to use the SCHEMA namespace prefix.
102-104: DeploymentVersion reference correctly updated.The transition from
releasetodeploymentVersionis properly implemented, maintaining consistent naming throughout the codebase.
109-111: Environment schema reference updated correctly.The reference to the environment schema has been properly updated to use the SCHEMA namespace.
packages/db/src/schema/job.ts (3)
49-49: Import change looks good.Correctly updated the import to reference
deploymentVersioninstead ofrelease, which aligns with the broader schema refactoring.
259-268: BuildVersionCondition function properly updated.All references to
release.versionhave been systematically updated todeploymentVersion.versionin the various condition checks. The changes are thorough and consistent.
275-277: BuildCondition function correctly refactored.The condition checks for
JobFilterType.DeploymentandJobFilterType.Releasehave been properly updated to usedeploymentVersionproperties instead ofreleaseproperties.Also applies to: 282-284
apps/webservice/src/app/[workspaceSlug]/(appv2)/_components/resources/ReleaseCell.tsx (3)
3-3: Type import consolidation looks good.Good approach to consolidate type imports using the namespace pattern, which is consistent with changes in other files.
18-20: ReleaseIcon component props properly updated.The type annotation for the job prop has been correctly updated to use the SCHEMA namespace.
76-81: ReleaseCell component props correctly refactored.The type annotations for the component props have been properly updated to use the SCHEMA namespace, including the change from
Partial<Release>toPartial<SCHEMA.DeploymentVersion>, maintaining consistency with the schema changes.apps/webservice/src/app/[workspaceSlug]/(appv2)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsx (2)
3-3: Import refactored to use a consolidated schema namespace.The change to import all schema types as a namespace (
SCHEMA) aligns with the broader refactoring effort to standardize schema imports across the codebase.
24-29: Type references properly updated to use the SCHEMA namespace.The prop types have been correctly updated to use the
SCHEMAnamespace, including the transition fromReleasetoDeploymentVersion, which aligns with the data model refactoring.packages/job-dispatch/src/policies/success-rate-criteria-passing.ts (3)
13-13: Parameter type updated from Release to DeploymentVersion.The parameter type change from
schema.Releasetoschema.DeploymentVersioncorrectly implements the data model refactoring.
69-70: Join condition updated to use deploymentVersion instead of release.The inner join condition has been correctly updated to use
schema.deploymentVersioninstead ofschema.release, maintaining consistency with the updated parameter types.
94-94:Details
✅ Verification successful
Verify reference to deployment_version in logic.
The result destructuring references
policy.deployment_version, which appears to be correct, but ensure this matches the column alias defined in the query.
🏁 Script executed:
#!/bin/bash # Check if the deployment_version alias is correctly used throughout the codebase rg -A 5 -B 5 "deployment_version" --type=tsLength of output: 55726
Deployment Version Alias Verified – No Changes Required
The verification confirms that the
policy.deployment_versionreference in the logic (specifically inpackages/job-dispatch/src/policies/success-rate-criteria-passing.ts) consistently matches the column alias defined in the database queries. All occurrences across the codebase, including tests and related queries, use the alias correctly.packages/api/src/router/release.ts (4)
21-21: Import refactored to use a consolidated schema namespace.The change to import all schema entities as a namespace (
SCHEMA) aligns with the broader refactoring effort to standardize schema imports across the codebase.
67-74: References properly updated to use SCHEMA namespace.The query references have been correctly updated to use the
SCHEMAnamespace, including the transition fromreleasetodeploymentVersionfor the deployment ID check and release condition matching.
178-178: Input type reference updated to use SCHEMA namespace.The procedure's input type has been correctly updated from
createReleasetoSCHEMA.createRelease.
215-215: Update procedure's input type properly refactored.The input type for the update procedure has been correctly updated to use
SCHEMA.updateRelease.apps/webservice/src/app/[workspaceSlug]/(app)/dependencies/DependencyDiagram.tsx (4)
3-3: Import refactored to use a consolidated schema namespace.The change to import all schema types as a namespace (
SCHEMA) aligns with the broader refactoring effort to standardize schema imports across the codebase.
106-106: Component prop type updated from Release to DeploymentVersion.The
releasesprop type in theReleaseSelectorcomponent has been correctly updated fromRelease[]toSCHEMA.DeploymentVersion[].
151-153: Node props type definition updated to use SCHEMA namespace.The type definition for the
DeploymentNodecomponent has been correctly updated to use theSCHEMAnamespace for theDeploymenttype.
227-229: Type definitions for deployments array updated correctly.The type definitions for the
deploymentsprop in bothDependencyDiagramandDiagramcomponents have been correctly updated to use theSCHEMAnamespace.Also applies to: 269-271
packages/db/src/schema/release.ts (7)
83-83: Foreign key reference update looks correct.Ensures that
releaseIdnow referencesdeploymentVersion.id. This aligns with the renamed entity and maintains referential integrity.
106-131: NewdeploymentVersiontable definition well-structured.Declares fields consistently with the new naming conventions. Defaulting
configandjobAgentConfigto{}seems correct; just confirm these defaults align with downstream usage.
133-133: Consistent type export.Exporting
DeploymentVersionhere completes the rename from the oldReleasetype. No concerns.
160-161: Foreign key reference aligns with the renamed table.Points to
deploymentVersion.idconsistently.
235-235: Metadata references todeploymentVersion.idare correct.These lines consistently change the reference from the old table to
deploymentVersion. Logical consistency is evident.Also applies to: 249-249, 264-264, 279-279, 294-294, 309-309
319-326:Details
❓ Verification inconclusive
Date filtering logic seems correct; consider timezone implications.
These lines appear correct for basic comparisons, but confirm that
new Date(cond.value)matches your intended timezone approach.
🏁 Script executed:
#!/bin/bash # Checking references to 'AT TIME ZONE' to confirm thorough timezone handling rg "AT TIME ZONE" -A5Length of output: 2385
Review: Verify Timezone Consistency for Date Filtering
The date comparisons in the schema appear correct for basic filtering. However, note that while other parts of the codebase (e.g., in packages/api) apply explicit timezone adjustments using "AT TIME ZONE", this function relies on raw date comparisons. Please ensure that the use of constructs like
new Date(cond.value)aligns with your intended timezone strategy. If the input dates should be normalized (e.g., converting to UTC) before comparison, then additional handling may be necessary.
- Confirm that the timezone assumed when parsing
cond.value(vianew Date) matches the expectations from other modules.- Consider whether explicit timezone conversion should be added in this file to maintain consistency with the API router logic.
330-337:Details
❓ Verification inconclusive
Version filtering logic appears correct; verify input sanitization.
ilikeand regex usage look good. Drizzle usually parameterizes queries, but ensurecond.valueis sanitized or validated to avoid injection edge cases.
🏁 Script executed:
#!/bin/bash # Ensure `cond.value` is validated in code. # Searching for buildVersionCondition references to confirm safe usage rg -A 10 "buildVersionCondition"Length of output: 3415
Ensure
cond.valueis safely validatedThe version filtering logic correctly uses Drizzle’s parameterized functions (e.g.,
eq,ilike, and thesqltemplate literal). However, as these functions rely on upstream input handling, please verify that any value assigned tocond.valueis appropriately validated or sanitized—especially for regex operations (using~) where injection risks may be subtler. Also, double-check that similar sanitization is in place in modules likepackages/db/src/schema/job.ts.packages/job-dispatch/src/policies/release-sequencing.ts (3)
37-38: Correct reference adjustments todeploymentVersion.The join conditions are properly updated to point to
schema.deploymentVersion. This is consistent with the renamed entity.Also applies to: 42-42, 55-55
129-129: Join & ordering logic updated todeploymentVersion.These lines correctly switch from the old
releasetable todeploymentVersionand order by itscreatedAtfield.Also applies to: 132-132, 147-147, 155-155
180-181: Query referencingdeploymentVersionis consistent.All relevant conditions utilize the updated table name and field references properly.
packages/api/src/router/job.ts (6)
49-50: Inner joins now referencingdeploymentVersion.Switching from
releasetodeploymentVersionis coherent with the rest of the refactor.Also applies to: 54-54
233-234: Count query references updated correctly.Using
deploymentVersionin the join conditions is consistent with the schema rename.Also applies to: 238-238
352-353: Daily count query for deployment references is correct.The switch to
deploymentVersionensures accurate joins.Also applies to: 357-357
418-418: Release ID check updated todeploymentVersion.id.Keeps naming in sync and ensures correct row selection.
516-516: Dependency references updated.
releaseDependency.releaseId→deploymentVersion.idis a valid rename alignment.
782-782: Metadata keys query referencingdeploymentVersion.All changed references (
.from(schema.deploymentVersion),eq(schema.releaseJobTrigger.releaseId, schema.deploymentVersion.id), and.where(eq(schema.deploymentVersion.id, input))) appear properly aligned with the new table name.Also applies to: 785-785, 795-795
packages/api/src/router/deployment.ts (20)
16-16: Refactored Schema Import
The new consolidated import usingimport * as SCHEMA from "@ctrlplane/db/schema";centralizes all schema references and simplifies maintenance. Please ensure that all previous individual schema imports have been removed from other parts of the code.
31-31: Updated Input Schema for Create Release Channel
Switching to.input(SCHEMA.createReleaseChannel)leverages the updated schema definitions. Verify that the underlyingSCHEMA.createReleaseChannelmatches the expected input structure for channel creation.
55-57: Consistent Use of Schema in Update Query
Updating the query withctx.db.update(SCHEMA.releaseChannel)...where(eq(SCHEMA.releaseChannel.id, input.id))ensures that the operation applies to the correct table and field. This change aligns with the refactored schema.
70-73: Deletion Operation Updated Using Schema Namespace
The mutation now deletes usingSCHEMA.releaseChannelwith a filtering condition on itsid. This refactoring centralizes the table reference and should simplify future schema changes.
119-125: Fetching Release Channel by ID with Schema Reference
The query correctly useseq(SCHEMA.releaseChannel.id, input)and joins related environment policy data. Ensure that the structure returned by thewithclause remains compatible with components consuming this data.
163-166: Hook List Query Updated with Schema Namespace
Filtering the hooks usingeq(SCHEMA.hook.scopeId, input)andeq(SCHEMA.hook.scopeType, "deployment")is consistent with the refactoring effort. Confirm that the join with therunhooks(and subsequentlyrunbook) still produces the desired result set.
183-185: Retrieving Hook by ID Using Schema
The query for fetching a hook by its ID now appropriately applies the schema reference (SCHEMA.hook). Downstream usage should be reviewed to ensure it correctly handles any changes in the hook’s data structure.
199-208: Consistent Hook Creation Flow Using Schema References
Using.input(SCHEMA.createHook)together with subsequent transactions onSCHEMA.deployment,SCHEMA.hook, andSCHEMA.runbookestablishes a uniform pattern. Please verify that the transaction maintains referential integrity, especially for the insertedrunbookandrunhookrecords.
249-256: Updated Hook Update Input Validation
The update procedure now validates its input againstSCHEMA.updateHook, ensuring that the updated structure conforms to the new schema definitions. This change helps keep the data model consistent across operations.
268-289: Schema Consistency in Hook Update Transaction
Within the transaction, updatingSCHEMA.hookand then fetching related deployment data viaSCHEMA.deploymentpreserves integrity. The deletion of the previousrunbook(usingSCHEMA.runbook) before inserting new records ensures a clean state.
297-319: Recreating Associated Records in Hook Update
The insertion of a newrunbook(and its optional variables) followed by creating a newrunhookis properly using the consolidated schema namespace. Review that the transactional boundaries are sufficient to maintain atomicity across these operations.
330-332: Schema Consistency in Hook Delete Authorization Check
The authorization query now referencesSCHEMA.hookcorrectly when verifying a hook's existence and scope. This change is in line with the overall refactoring and simplifies future schema updates.
342-343: Hook Deletion Mutation with Schema Namespace
Usingctx.db.delete(SCHEMA.hook).where(eq(SCHEMA.hook.id, input))for deletion aligns with the refactored import strategy. This reinforces the consistency in how schema entities are referenced across mutations.
360-372: Refactored Query for Latest Jobs Per Resource
The construction of the "latest_jobs" alias now leverages schema references (SCHEMA.jobandSCHEMA.releaseJobTrigger) along with a window function for ranking. Ensure that the SQL expression using template literals is valid and performs as expected.
414-420: Deployment Creation with Updated Schema
Using.input(SCHEMA.createDeployment)and inserting intoSCHEMA.deploymentwith a default empty string for a missing description ensures a smooth creation path. Confirm that the schema for deployments is comprehensive and up-to-date.
430-433: Deployment Update Procedure Consistency
The update procedure now validates its input viaSCHEMA.updateDeploymentand then invokes the externalupdateDeploymentfunction. Please verify that the external function uses the correct schema references internally.
443-456: Deployment Deletion with Event Handling
This deletion mutation first retrieves deployment details usingSCHEMA.deployment, then processes related events before deleting the record. Confirm that the event handling withgetEventsForDeploymentRemovedremains compatible with the updated schema structures.
468-471: Retrieve Deployment by ID Using Schema
The simple query to fetch a deployment by its ID now consistently usesSCHEMA.deploymentand should seamlessly integrate with downstream modules expecting the updated data format.
564-591: Group By and Join Logic in BySystemId Query
The query groups deployments by system and aggregates release channels while joining withSCHEMA.systemandSCHEMA.releaseChannel. Confirm that the lodash chain operations (especially theuniqByon channel id) correctly deduplicate channels according to the new schema.
711-716: Deployment ByWorkspaceId Query
The query correctly joinsSCHEMA.deploymentandSCHEMA.systemand filters byworkspaceId. Ensure that the workspace filtering logic reflects any schema changes made during the refactor.
Summary by CodeRabbit
Refactor
Chores