fix: Deployment version metadata router #376
Conversation
WalkthroughThis pull request refactors the handling of release-related metadata by renaming references from release concepts to deployment version concepts. All affected components—from API routes and routers to database schema definitions and job-dispatch logic—now use deployment version terminology. The changes involve updating schema names, function calls, and join conditions while preserving the overall control flow and behavior of the system. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Router
participant Service
participant DB
Client->>Router: HTTP Request (create/update deployment version)
Router->>Service: Process request using deployment version schemas
Service->>DB: Execute query with deploymentVersionMatchesCondition
DB-->>Service: Return metadata response
Service-->>Router: Process result
Router-->>Client: Response with deployment version data
Possibly related PRs
Suggested reviewers
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
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/db/src/schema/release.ts (1)
1-364: Consider renaming the file to match the new terminology.While all the schema references have been updated, the file itself is still named
release.ts. For complete consistency, consider renaming the file todeployment-version.tsas part of this refactoring.Additionally, there are still numerous references to "release" in variable names, constants, and types throughout the file (e.g.,
releaseChannel,releaseId,ReleaseStatus). Consider renaming these for full consistency.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
apps/webservice/src/app/api/v1/config/route.ts(1 hunks)apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts(1 hunks)apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts(3 hunks)apps/webservice/src/app/api/v1/releases/route.ts(3 hunks)packages/api/src/router/deployment-version.ts(8 hunks)packages/api/src/router/deployment.ts(1 hunks)packages/api/src/router/release-metadata-keys.ts(3 hunks)packages/db/src/schema/release.ts(9 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/policies/release-dependency.ts(1 hunks)packages/job-dispatch/src/policies/release-sequencing.ts(1 hunks)packages/job-dispatch/src/policies/release-string-check.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.
packages/job-dispatch/src/policies/release-dependency.tsapps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.tspackages/job-dispatch/src/environment-creation.tspackages/job-dispatch/src/policies/release-string-check.tspackages/job-dispatch/src/environment-release-channel-update.tspackages/api/src/router/release-metadata-keys.tsapps/webservice/src/app/api/v1/config/route.tspackages/api/src/router/deployment.tsapps/webservice/src/app/api/v1/releases/[releaseId]/route.tsapps/webservice/src/app/api/v1/releases/route.tspackages/job-dispatch/src/resource/dispatch-resource.tspackages/db/src/schema/release.tspackages/job-dispatch/src/policies/release-sequencing.tspackages/api/src/router/deployment-version.ts
🧠 Learnings (1)
packages/api/src/router/deployment.ts (1)
Learnt from: adityachoudhari26
PR: ctrlplanedev/ctrlplane#181
File: packages/api/src/router/deployment.ts:116-131
Timestamp: 2025-03-12T21:38:05.695Z
Learning: In `packages/api/src/router/deployment.ts`, the `list.byDeploymentId` procedure requires multiple database queries due to limitations of the `releaseMatchesCondition` function.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Typecheck
- GitHub Check: Lint
- GitHub Check: build (linux/amd64)
🔇 Additional comments (30)
apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)
42-46: Schema reference update looks goodThe join operation has been correctly updated from
SCHEMA.releaseMetadatatoSCHEMA.deploymentVersionMetadatawith the appropriate join condition matching thereleaseIdwithSCHEMA.deploymentVersion.id. This change aligns with the overall refactoring effort to shift from release concepts to deployment version concepts.packages/job-dispatch/src/policies/release-dependency.ts (1)
121-121: Function update is consistent with refactoring approachThe change from
schema.releaseMatchesConditiontoschema.deploymentVersionMatchesConditionis appropriate and maintains the same parameters, ensuring consistent behavior while aligning with the deployment version terminology.packages/job-dispatch/src/resource/dispatch-resource.ts (1)
89-92: Schema condition function correctly updatedThe change from
SCHEMA.releaseMatchesConditiontoSCHEMA.deploymentVersionMatchesConditionis properly implemented, maintaining the same parameters and behavior while adopting the new deployment version terminology.packages/job-dispatch/src/environment-creation.ts (1)
60-63: Condition function updated consistentlyThe change from
SCHEMA.releaseMatchesConditiontoSCHEMA.deploymentVersionMatchesConditionis consistent with the other files in the PR, preserving the same function signature while shifting to deployment version terminology.packages/job-dispatch/src/policies/release-string-check.ts (1)
92-92: Terminology update consistent with deployment version refactoringThe function call has been updated from
schema.releaseMatchesConditiontoschema.deploymentVersionMatchesConditionwhile maintaining the same parameters, aligning with the PR's objective to refactor release concepts to deployment version concepts.packages/job-dispatch/src/environment-release-channel-update.ts (2)
83-83: Function call updated to use deployment version terminologyThe condition check has been updated from
SCHEMA.releaseMatchesConditiontoSCHEMA.deploymentVersionMatchesConditionwhile maintaining the same parameters and functionality, consistent with the PR's refactoring objective.
107-107: Consistent terminology update for deployment versionThis change from
SCHEMA.releaseMatchesConditiontoSCHEMA.deploymentVersionMatchesConditionmaintains consistency with the overall refactoring from release concepts to deployment version concepts throughout the codebase.packages/job-dispatch/src/policies/release-sequencing.ts (1)
149-152: Function call updated to match deployment version terminologyThe condition check has been properly updated to use
schema.deploymentVersionMatchesConditioninstead of the previous release-based terminology, maintaining consistency with the PR's objective while preserving the function's behavior.apps/webservice/src/app/api/v1/config/route.ts (1)
238-240: Database schema target updated to deploymentVersionMetadataThe insertion target has been changed from
schema.releaseMetadatatoschema.deploymentVersionMetadatawhile maintaining the same data structure (releaseMetadataInserts). This change aligns with the PR's objective of refactoring release-related metadata to use deployment version concepts.packages/api/src/router/deployment.ts (1)
99-99: Function call updated to match new schema namingThe code now uses
SCHEMA.deploymentVersionMatchesConditioninstead ofSCHEMA.releaseMatchesCondition, which aligns with the PR objective to rename release-related concepts to deployment version concepts.packages/api/src/router/release-metadata-keys.ts (3)
10-10: Router export name updated to reflect deployment version conceptThe router has been renamed from
releaseMetadataKeysRoutertodeploymentVersionMetadataKeysRouterto align with the PR's objective of refactoring release concepts to deployment version concepts.
22-29: Schema references updated from 'releaseMetadata' to 'deploymentVersionMetadata'All schema references in the
bySystemprocedure have been updated to use the newdeploymentVersionMetadataschema instead ofreleaseMetadata, maintaining consistent naming throughout the codebase.
50-57: Schema references updated in 'byWorkspace' procedureSimilar to the
bySystemprocedure, all schema references in thebyWorkspaceprocedure have been updated to use the newdeploymentVersionMetadataschema.packages/api/src/router/deployment-version.ts (7)
47-47: Import updated to use new router nameThe import statement has been updated to use the renamed
deploymentVersionMetadataKeysRouterinstead ofreleaseMetadataKeysRouter, maintaining consistency with the changes in the release-metadata-keys.ts file.
71-74: Condition function updated to match deployment version namingThe function call has been updated from
SCHEMA.releaseMatchesConditiontoSCHEMA.deploymentVersionMatchesConditionto maintain consistent naming throughout the codebase.
161-162: Schema references updated in byId queryThe metadata retrieval logic now uses
SCHEMA.deploymentVersionMetadatainstead ofSCHEMA.releaseMetadatato maintain consistent naming throughout the codebase.
178-178: Input schema updated to use deployment version schemaThe input schema reference has been updated from
SCHEMA.createReleasetoSCHEMA.createDeploymentVersionto align with the PR's objective of refactoring release concepts to deployment version concepts.
215-217: Update input schema reference changedThe update procedure's input schema has been updated to use
SCHEMA.updateDeploymentVersioninstead ofSCHEMA.updateRelease, maintaining consistency with the overall renaming approach.
621-625: Condition check updated in ternary expressionThe conditional check now uses
SCHEMA.deploymentVersionMatchesConditioninstead ofSCHEMA.releaseMatchesCondition, ensuring consistent naming throughout the codebase.
676-676: Router reference updated in exported objectThe
metadataKeysproperty now references the renameddeploymentVersionMetadataKeysRouterinstead ofreleaseMetadataKeysRouter, maintaining consistency with the router import change.apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts (2)
22-24: Patch schema updated to use deployment version schemaThe
patchSchemaconstant now extendsSCHEMA.updateDeploymentVersioninstead ofSCHEMA.updateRelease, aligning with the codebase-wide renaming from release to deployment version.
51-69: Metadata handling updated to use deployment version schemaThe metadata insertion and conflict resolution logic has been updated to use
SCHEMA.deploymentVersionMetadatainstead ofSCHEMA.releaseMetadata, maintaining consistent naming throughout the codebase while preserving the same functionality.apps/webservice/src/app/api/v1/releases/route.ts (3)
30-35: Schema reference updated correctly, but the validation structure is preserved.The schema reference has been properly updated from
createReleasetocreateDeploymentVersion, maintaining the existing validation structure for the body schema.
86-103: Schema references updated consistently for metadata operations.All references to the metadata schema have been updated from
releaseMetadatatodeploymentVersionMetadata, ensuring consistency in the database operations while preserving the same conflict resolution logic.
37-149:❓ Verification inconclusive
Verify that all references to "release" in strings and logs reflect the new terminology.
While the schema references have been updated, log messages and variable names continue to use "release" terminology. For consistency, consider updating these references as well.
🏁 Script executed:
#!/bin/bash # Search for occurrences of "release" in log messages and string literals rg -i "release" --type ts --type tsx --glob "!**/release.ts" apps/webservice/src/app/api/v1/releases/Length of output: 129
Action Required: Ensure Consistent Terminology Updates in Logs and Strings
The updated schema now uses the new terminology, but several hard-coded references to “release” remain within string literals and log messages (for example,
"Release for ${release.id} job triggers created and dispatched."and"Error creating release:"inapps/webservice/src/app/api/v1/releases/route.ts). Please verify that these log messages and any other similar string literals—across not just this file but the entire releases API—are updated to reflect the new terminology.
- Confirm that the log statements and any user-facing strings no longer use the outdated “release” term.
- Check related files in the releases module for any additional mismatches.
packages/db/src/schema/release.ts (5)
135-151: Schema definition renamed from createRelease to createDeploymentVersion.The schema definition has been renamed to align with the new terminology while maintaining the same validation rules and structure.
153-154: Update schema types appropriately created.The update schema has been renamed consistently with a new type definition that properly references the updated schema.
155-166: Table definition renamed while preserving structure.The table definition has been updated from
releaseMetadatatodeploymentVersionMetadatawhile maintaining the same column structure and constraints.Note that the column
releaseIdstill references the deployment version concept despite its name. This is likely for backward compatibility with existing data.
227-315: Metadata condition building updated consistently.All references to the metadata table in the
buildMetadataConditionfunction have been updated to usedeploymentVersionMetadata, ensuring the query logic works with the renamed table.
356-363: Function renamed while preserving functionality.The function has been renamed from
releaseMatchesConditiontodeploymentVersionMatchesConditionwhile maintaining the same parameter structure and return type.
Summary by CodeRabbit