fix: More release dep version refactor #385
Conversation
WalkthroughThis pull request refactors the entire codebase to replace “release” terminology with “deployment version” terminology. Database query join conditions, API routes, component props, schema definitions, and validation types are updated accordingly. References like releaseId/version are changed to versionId/tag, and related enums and policies have been renamed. Both client-side components and server-side modules—including job dispatchers, API endpoints, database schemas, and validators—are aligned to consistently use the new naming convention. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
participant Database
Client->>API: Request deployment version check/update
API->>Database: Execute query using versionId (e.g., compare environmentPolicyApproval.versionId with trigger.versionId)
Database-->>API: Return matching deployment version details
API-->>Client: Respond with deployment version data
Possibly related PRs
Poem
✨ Finishing Touches
🪧 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: 3
🔭 Outside diff range comments (2)
packages/job-dispatch/src/release-job-trigger.ts (1)
3-6: 💡 Verification agent🧩 Analysis chain
Consider updating remaining release terminology for complete consistency.
While most of the code has been updated to use "version" terminology, there are still several instances where "release" terminology remains:
- Type definitions (lines 3-6):
ReleaseJobTrigger,ReleaseJobTriggerInsert,ReleaseJobTriggerType- Function parameters (lines 14-22): Using
releaseJobTriggersandinsertReleaseJobTriggers- Schema reference (line 230):
SCHEMA.releaseJobTriggerFor complete consistency with the refactoring effort, consider updating these remaining instances as well.
Also applies to: 14-22, 229-232
🏁 Script executed:
#!/bin/bash # Check for other files that might still use the old terminology rg -A 2 -B 2 "ReleaseJobTrigger" --type ts rg "releaseJobTrigger" --type tsLength of output: 68276
Action: Update "release" terminology consistently to "version" across the codebase.
The search results reveal that while the file in question (packages/job-dispatch/src/release-job-trigger.ts) shows a partial update, many other parts of the codebase still use the old "release" terms. For complete consistency with the refactoring effort, please update the following:
Type Definitions:
- In
packages/job-dispatch/src/release-job-trigger.ts(lines 3–6), updateReleaseJobTrigger,ReleaseJobTriggerInsert, andReleaseJobTriggerTypeto new names (e.g.,VersionJobTrigger,VersionJobTriggerInsert,VersionJobTriggerType).Function Parameters and Variables:
- Replace instances of
releaseJobTriggers,insertReleaseJobTriggers, and similar identifiers in functions across files such ascancel-previous-jobs.ts,deployment-update.ts, and others.Schema and API References:
- Update references like
SCHEMA.releaseJobTriggerin schema definitions and API routes to reflect the new "version" terminology.- Ensure consistency in test files and documentation as well.
Given the breadth of occurrences identified in multiple modules (including policies, job dispatch, API routes, and UI components), a comprehensive renaming (possibly via a global search–replace with careful review) is recommended.
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsx (1)
147-152: 💡 Verification agent🧩 Analysis chain
Component name still using Release terminology.
While the prop has been updated to use
deploymentVersion, the component nameReleaseDropdownMenustill uses the old terminology.Consider verifying if the
ReleaseDropdownMenucomponent needs to be renamed for consistency:
🏁 Script executed:
#!/bin/bash # Find all occurrences of ReleaseDropdownMenu to see if it's used elsewhere rg "ReleaseDropdownMenu" -A 3Length of output: 7393
Rename component for consistency with new deployment terminology
The component's prop has been updated to use
deploymentVersion, but the component name (ReleaseDropdownMenu) and its location under the "release" directory have not been adjusted, leading to inconsistencies across the codebase. Based on the grep output, this component is used in several places (e.g., in TableCells.tsx, ReleaseEnvironmentCell.tsx, and ReleaseInfo.tsx). Consider refactoring the component name (and associated file/folder names if applicable) to something likeDeploymentDropdownMenuto align with the updated terminology. Be sure to update all references and import paths accordingly.
- Files to update:
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ReleaseDropdownMenu.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/TableCells.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsx
🧹 Nitpick comments (20)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsx (1)
60-63: Consider updating URL helper function name.While all other references have been updated, the
getReleaseUrlfunction name and the.releaseproperty in the URL construction still use the old "release" terminology. For complete consistency, consider updating these to match the new "deployment version" terminology.- const getReleaseUrl = urls - .workspace(workspaceSlug) - .system(systemSlug) - .deployment(deployment.slug).release; + const getVersionUrl = urls + .workspace(workspaceSlug) + .system(systemSlug) + .deployment(deployment.slug).version;apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ReleaseDropdownMenu.tsx (1)
1-209: Consider renaming component files and class names for complete terminology consistencyWhile the props and references have been updated to use the new "deploymentVersion" terminology, the component names themselves (RedeployReleaseDialog, ForceReleaseDialog, RedeployReleaseButton, ReleaseDropdownMenu) and the file name (ReleaseDropdownMenu.tsx) still use the old "release" terminology. For complete consistency, consider renaming these in a future update.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/useReleaseFilter.ts (1)
7-15: Consider updating parameter names for complete consistency.The parameter names in URLs still use "release" terminology (
release_channel_id_filter) while the variable names use the updated terminology. This might be intentional for backward compatibility, but it's worth noting.packages/job-dispatch/src/release-job-trigger.ts (1)
122-122: Variable name inconsistency.The variable
releaseJobTriggerson line 122 is still using the old terminology while being initialized withversionIds. For consistency, consider renaming this toversionJobTriggersor similar.- const releaseJobTriggers = this.versionIds + const versionJobTriggers = this.versionIdsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ApprovalDialog.tsx (1)
66-67: UI text still references "release" but uses deploymentVersion.tagWhile the component has been updated to use
deploymentVersioninstead ofrelease, the UI text still mentions "release". Consider updating the text to "Approve deployment version" for consistency.- Approve release{" "} + Approve deployment version{" "}packages/api/src/router/environment-approval.ts (1)
153-182: Improved job cancellation logicThe job cancellation logic has been significantly refactored to first explicitly select the jobs to cancel and then update them using the
inArrayfunction. This is a more structured and maintainable approach compared to the previous SQL execution method.The code now properly:
- Queries jobs that need to be cancelled
- Uses
inArrayto update job statuses efficiently- Returns the count of cancelled jobs
Consider adding error handling around the database operations to ensure that cancellation failures are properly logged and managed.
try { const jobs = await tx .select() .from(SCHEMA.job) // ... rest of the query ... await tx .update(SCHEMA.job) .set({ status: JobStatus.Cancelled }) // ... rest of the update ... return { cancelledJobCount: jobs.length }; } catch (error) { console.error("Failed to cancel jobs:", error); throw new TRPCError({ code: "INTERNAL_SERVER_ERROR", message: "Failed to cancel jobs", }); }apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)
83-91: Consider removing duplicate data structureA new
versionproperty has been added that mirrors the existingreleaseproperty. This appears to be part of a transition strategy to maintain backward compatibility, but it creates duplicate data in the response.Consider adding a deprecation notice in JSDoc for the
releaseproperty to indicate it will be removed in a future version.release: jobRows[0]!.deployment_version != null ? { ...jobRows[0]!.deployment_version, metadata: jobRows .map((r) => r.deployment_version_metadata) .filter(isPresent), } + // @deprecated Use 'version' instead. This will be removed in a future version. : null,apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/layout.tsx (1)
30-102: Consider updating URL pattern in the futureWhile the variable names and property references have been updated, the URL pattern still uses
/releases/[releaseId]/in the path. For complete terminology consistency, consider updating these URL patterns in a future PR.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/EnvironmentNode.tsx (2)
42-69: Function parameter updated but function name remains inconsistent.The
WaitingOnActiveCheckcomponent has been updated to useversionIdinstead ofreleaseId, but theisSameReleasevariable name and its related logic still use "release" terminology.Consider renaming
isSameReleasetoisSameVersionfor consistency with the new terminology:-const isSameRelease: JobReleaseCondition = { +const isSameVersion: JobReleaseCondition = { type: JobFilterType.Release, operator: ColumnOperator.Equals, value: versionId, };And similarly updating other variables like
isDifferentRelease,pendingJobsForCurrentReleaseAndEnvFilter, etc.
147-194: UI text still using "release channel" terminology.While the code logic has been updated to use version terminology, the UI text still displays "release channel" which may confuse users.
Consider updating the UI text to match the new terminology:
- release channel + version channelat lines 169 and 188.
apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts (1)
30-35: Authorization check still using old terminology.While most of the file has been updated to use the new "version" terminology, the authorization check is still using "deploymentVersion" with the parameter
releaseId.Consider updating the authorization check to use consistent parameter naming:
authz(({ can, extra: { params } }) => can .perform(Permission.DeploymentVersionUpdate) - .on({ type: "deploymentVersion", id: params.releaseId }), + .on({ type: "deploymentVersion", id: params.releaseId /* or rename to versionId in the route */ }), ),apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsx (3)
34-44: Variable renamed while preserving loading state naming.The
datavariable has been renamed fromreleasetodeploymentVersionto align with the new terminology, but note thatisReleaseLoadinghasn't been renamed. The query parameter has also been updated to useversionIdinstead ofreleaseId.Consider also renaming
isReleaseLoadingtoisVersionLoadingfor complete consistency:-const { data: deploymentVersion, isLoading: isReleaseLoading } = +const { data: deploymentVersion, isLoading: isVersionLoading } =
62-65: Updated no version check message.The message has been updated from "No releases released" to "No versions released", which aligns with the new terminology but is a slight tautology.
Consider rewording to avoid the repetition:
-<p className="text-xs text-muted-foreground/70">No versions released</p> +<p className="text-xs text-muted-foreground/70">No versions available</p>
97-99: Variable still using showRelease terminology.The variable
showReleasestill uses the old terminology while the code around it has been updated.Consider renaming for consistency:
-const showRelease = isAlreadyDeployed && !isPendingApproval; +const showVersion = isAlreadyDeployed && !isPendingApproval;And updating its usage at line 99.
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/channels/CreateDeploymentVersionChannelDialog.tsx (3)
112-113: UI text still references "Release Channel" instead of "Deployment Version Channel".While the code has been updated to use the new terminology, the DialogTitle still uses "Create Release Channel". Consider updating this to maintain consistency with the deployment version terminology used throughout the codebase.
- <DialogTitle>Create Release Channel</DialogTitle> + <DialogTitle>Create Deployment Version Channel</DialogTitle>
150-151: UI text still references "Release Filter".For consistency with the terminology changes in the code, consider updating this label to "Version Filter" or "Deployment Version Filter".
- <FormLabel>Release Filter ({releases?.total ?? "-"})</FormLabel> + <FormLabel>Version Filter ({releases?.total ?? "-"})</FormLabel>
178-179: UI text still references "View releases".For consistency with the deployment version terminology, consider updating this button text.
- View releases + View versionspackages/validators/src/releases/conditions/release-condition.ts (1)
98-105: Function name mismatch: consider renaming for clarity.
The function is namedisValidReleaseConditionbut it accepts aDeploymentVersionCondition, which can be confusing. Consider renaming it to align with "deployment version."-export const isValidReleaseCondition = ( +export const isValidDeploymentVersionCondition = ( condition: DeploymentVersionCondition, ): boolean => { ... }packages/job-dispatch/src/environment-release-channel-update.ts (2)
14-14: File naming suggestion for better consistency.Because the code now focuses on version logic, consider renaming
release-string-check.jsto evidence the new naming convention (e.g.,version-string-check.js) to avoid confusion.
114-125: Consider renaming local variables for consistency.The function is now
triggerJobsForVersion, but the local variable is stillreleaseJobTriggers. You may rename it (and related references) to “versionJobTriggers” for complete alignment, for example:- const releaseJobTriggers = await createReleaseJobTriggers( + const versionJobTriggers = await createReleaseJobTriggers(
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (85)
apps/jobs/src/policy-checker/index.ts(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/ApprovalCheck.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/EnvironmentNode.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/page.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/page.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/EnvironmentApprovalRow.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/ResourceReleaseTable.tsx(9 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/layout.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/properties/page.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/DeploymentPageContent.tsx(11 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/DeployButton.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx(9 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/TableCells.tsx(6 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionBarChart.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/channels/CreateDeploymentVersionChannelDialog.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/environments/[environmentId]/resources/EnvironmentResourcesTable.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsx(10 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/ReleaseInfo.tsx(5 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ApprovalDialog.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/CreateRelease.tsx(10 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ReleaseDropdownMenu.tsx(10 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/channel/drawer/Overview.tsx(4 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/JobDropdownMenu.tsx(10 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobDrawer.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobProperties.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ComparisonConditionRender.tsx(11 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionBadge.tsx(4 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionDialog.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionRender.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/release-condition-props.ts(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/useReleaseFilter.ts(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/ReleaseCell.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/drawer/DeploymentContent.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_hooks/channel/useDeploymentVersionChannel.ts(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/resources/(raw)/[resourceId]/deployments/ResourceDeploymentRow.tsx(1 hunks)apps/webservice/src/app/api/v1/config/route.ts(4 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(4 hunks)apps/webservice/src/app/api/v1/releases/[releaseId]/openapi.ts(2 hunks)apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts(5 hunks)apps/webservice/src/app/api/v1/releases/openapi.ts(2 hunks)apps/webservice/src/app/api/v1/releases/route.ts(5 hunks)packages/api/src/router/deployment-variable.ts(2 hunks)packages/api/src/router/deployment-version.ts(23 hunks)packages/api/src/router/deployment.ts(2 hunks)packages/api/src/router/environment-approval.ts(8 hunks)packages/api/src/router/environment-policy.ts(2 hunks)packages/api/src/router/environment.ts(3 hunks)packages/api/src/router/job.ts(11 hunks)packages/api/src/router/resource-stats.ts(1 hunks)packages/api/src/router/resources.ts(2 hunks)packages/api/src/router/version-deploy.ts(5 hunks)packages/api/src/router/version-metadata-keys.ts(2 hunks)packages/db/drizzle/0078_wandering_morph.sql(1 hunks)packages/db/drizzle/meta/_journal.json(1 hunks)packages/db/src/schema/deployment-version.ts(14 hunks)packages/db/src/schema/environment.ts(3 hunks)packages/db/src/schema/index.ts(2 hunks)packages/db/src/schema/job.ts(2 hunks)packages/db/src/schema/release-channel-relations.ts(1 hunks)packages/db/src/schema/release-channel.ts(1 hunks)packages/db/src/schema/release-job-trigger.ts(1 hunks)packages/db/src/schema/resource.ts(1 hunks)packages/job-dispatch/src/__test__/job-variables-deployment.test.ts(3 hunks)packages/job-dispatch/src/deployment-update.ts(3 hunks)packages/job-dispatch/src/environment-creation.ts(4 hunks)packages/job-dispatch/src/environment-release-channel-update.ts(9 hunks)packages/job-dispatch/src/job-creation.ts(2 hunks)packages/job-dispatch/src/job-failure.ts(1 hunks)packages/job-dispatch/src/policies/gradual-rollout.ts(2 hunks)packages/job-dispatch/src/policies/manual-approval.ts(1 hunks)packages/job-dispatch/src/policies/release-dependency.ts(2 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/policy-create.ts(1 hunks)packages/job-dispatch/src/release-job-trigger.ts(7 hunks)packages/job-dispatch/src/resource/dispatch-resource.ts(5 hunks)packages/validators/src/cac/index.ts(3 hunks)packages/validators/src/releases/conditions/release-condition.ts(3 hunks)packages/validators/src/releases/index.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-string-check.tspackages/job-dispatch/src/policy-create.tsapps/webservice/src/app/api/v1/releases/[releaseId]/openapi.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/environments/[environmentId]/resources/EnvironmentResourcesTable.tsxpackages/job-dispatch/src/deployment-update.tsapps/webservice/src/app/[workspaceSlug]/(app)/resources/(raw)/[resourceId]/deployments/ResourceDeploymentRow.tsxpackages/job-dispatch/src/policies/manual-approval.tspackages/job-dispatch/src/policies/release-sequencing.tspackages/api/src/router/resource-stats.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/ReleaseCell.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/layout.tsxpackages/api/src/router/environment-policy.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobProperties.tsxapps/jobs/src/policy-checker/index.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobDrawer.tsxapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/useReleaseFilter.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/EnvironmentApprovalRow.tsxpackages/db/src/schema/release-channel-relations.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/drawer/DeploymentContent.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionBarChart.tsxapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionRender.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/DeployButton.tsxpackages/db/src/schema/release-channel.tspackages/api/src/router/resources.tspackages/db/src/schema/index.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/channels/CreateDeploymentVersionChannelDialog.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/properties/page.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/TableCells.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/ApprovalCheck.tsxpackages/db/src/schema/resource.tsapps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.tspackages/job-dispatch/src/environment-creation.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/page.tsxpackages/api/src/router/deployment.tspackages/api/src/router/deployment-variable.tspackages/validators/src/releases/index.tsapps/webservice/src/app/api/v1/releases/[releaseId]/route.tsapps/webservice/src/app/api/v1/jobs/[jobId]/route.tspackages/job-dispatch/src/policies/release-dependency.tspackages/job-dispatch/src/job-failure.tsapps/webservice/src/app/[workspaceSlug]/(app)/_hooks/channel/useDeploymentVersionChannel.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/EnvironmentNode.tsxpackages/db/src/schema/job.tsapps/webservice/src/app/api/v1/releases/openapi.tspackages/job-dispatch/src/job-creation.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/release-condition-props.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionDialog.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsxapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionBadge.tsxpackages/validators/src/cac/index.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsxpackages/validators/src/releases/conditions/release-condition.tspackages/job-dispatch/src/__test__/job-variables-deployment.test.tsapps/webservice/src/app/api/v1/config/route.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/page.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ApprovalDialog.tsxpackages/job-dispatch/src/policies/gradual-rollout.tspackages/job-dispatch/src/release-job-trigger.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ComparisonConditionRender.tsxpackages/api/src/router/version-deploy.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/ReleaseInfo.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/DeploymentPageContent.tsxpackages/api/src/router/environment.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/job/JobDropdownMenu.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsxpackages/db/src/schema/environment.tspackages/api/src/router/version-metadata-keys.tsapps/webservice/src/app/[workspaceSlug]/(app)/_components/channel/drawer/Overview.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/ResourceReleaseTable.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ReleaseDropdownMenu.tsxpackages/db/src/schema/release-job-trigger.tspackages/api/src/router/environment-approval.tspackages/db/src/schema/deployment-version.tspackages/job-dispatch/src/environment-release-channel-update.tspackages/job-dispatch/src/resource/dispatch-resource.tsapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/CreateRelease.tsxpackages/api/src/router/deployment-version.tspackages/api/src/router/job.tsapps/webservice/src/app/api/v1/releases/route.ts
🪛 Biome (1.9.4)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx
[error] 27-27: Shouldn't redeclare 'DeploymentVersion'. Consider to delete it or rename it.
'DeploymentVersion' is defined here:
(lint/suspicious/noRedeclare)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Lint
- GitHub Check: build (linux/amd64)
🔇 Additional comments (414)
apps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/drawer/DeploymentContent.tsx (1)
50-50: Property access path updated to match deployment version restructuring.The code now accesses the deployment version through
deployment.releaseJobTrigger?.version.taginstead of the previousdeployment.releaseJobTrigger?.release.version, which aligns with the PR objective of refactoring "release" terminology to "deployment version" terminology. The fallback handling remains intact, maintaining the same component functionality.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/DeploymentDirectoryCell.tsx (8)
27-27: Props updated to use new terminology.The parameter type has been correctly updated from
release?todeploymentVersion?in the props type definition, which aligns with the PR's objective of replacing "release" terminology with "deployment version" terminology.
32-32: Component parameter destructuring updated.The destructured parameter has been consistently renamed from
releasetodeploymentVersion, matching the updated props type definition.
36-47: Query hooks updated to use deployment version terminology.The data fetching logic has been properly updated to use the new terminology:
- Variable names changed from release-related to version-related
- Query parameters updated
- Conditional enabling logic updated to check
deploymentVersioninstead ofreleaseThis maintains the same functionality while using the new naming convention.
49-49: Variable renamed to match new terminology.Correctly renamed from likely
rel(for release) toversionto be consistent with the new terminology.
53-54: API query parameters updated.The query parameters have been updated from using
releaseIdtoversionId, and the conditional check now usesversioninstead of the previous release-related variable.
56-56: Loading state variable updated.Loading state variable has been updated to match the new terminology.
77-77: Conditional rendering updated.Conditional rendering logic has been updated to check for
versioninstead of the previous release-related variable.Also applies to: 81-81
84-84: Data access updated to use version properties.All data accesses have been correctly updated to reference the
versionobject instead of the previous release-related object.Also applies to: 94-94, 98-98, 104-104
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ReleaseDropdownMenu.tsx (4)
47-51: Props and terminology updated correctly in RedeployReleaseDialogThe component has been updated to use
deploymentVersioninstead ofreleasein props, destructuring, and references. The UI text has also been updated to reflect the terminology change from "release" to "version". The API parameter has been correctly changed fromreleaseIdtoversionId.Also applies to: 64-64, 69-69, 80-80
96-100: Props updated in ForceReleaseDialog but UI text still contains "release" referencesWhile the props have been updated correctly, there are still references to "release" in the dialog text. Line 109 has been updated, but lines this dialog still has "release" mentions in lines 112-113: "This will force the release to be deployed...".
Consider updating all instances of "release" terminology in the UI text for consistency:
<AlertDialogDescription> - This will force the release to be deployed to all resources in the + This will force the version to be deployed to all resources in the environment regardless of any policies set on the environment. </AlertDialogDescription>Also applies to: 109-109, 125-125
139-143: RedeployReleaseButton props and references updated correctlyThe component has been updated to use
deploymentVersioninstead ofreleasein props, destructuring, and in the child component. The changes are consistent with the terminology shift in the codebase.Also applies to: 160-163
174-178: ReleaseDropdownMenu props and references updated correctlyThe exported component has been updated to use
deploymentVersioninstead ofreleasein props and destructuring. The props passed to child components have also been updated consistently.Also applies to: 191-191, 195-198
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/release-condition-props.ts (1)
1-1: Type update looks good.The change from
ReleaseConditiontoDeploymentVersionConditionis consistent with the PR objectives to refactor release terminology to deployment version terminology.Also applies to: 3-10
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/useReleaseFilter.ts (2)
1-1: Import update correctly aligned.The import change from
ReleaseConditiontoDeploymentVersionConditionis consistent with the terminology refactoring.
17-17: Type annotations properly updated.Both useMemo's return type and the setFilter parameter type are correctly updated to use
DeploymentVersionCondition.Also applies to: 28-28
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionBadge.tsx (5)
6-9: Import updates correctly aligned.The change to import
DeploymentVersionConditioninstead ofReleaseConditionis consistent with the terminology refactoring.
22-24: Enum import correctly updated.The change from
ReleaseOperatortoDeploymentVersionOperatormaintains consistency with the new terminology.
30-40: Operator mapping correctly updated.All operator references are properly updated to use
DeploymentVersionOperatorinstead ofReleaseOperator.
185-190: Component prop type correctly updated.The
StringifiedReleaseConditioncomponent's prop type is properly updated to useDeploymentVersionCondition.
215-217: Component prop type correctly updated.The
ReleaseConditionBadgecomponent's prop type is properly updated to useDeploymentVersionCondition.apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionRender.tsx (2)
1-1: Import update correctly aligned.The change from
ReleaseConditiontoDeploymentVersionConditionis consistent with the terminology refactoring.
21-23: Component type parameter correctly updated.The
ReleaseConditionRendercomponent's type parameter is properly updated to useDeploymentVersionCondition.apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ReleaseConditionDialog.tsx (3)
4-4: Type import updated for consistency.Import has been updated from
ReleaseConditiontoDeploymentVersionConditionas part of the terminology refactoring.
39-45: Props type updated to use deployment version terminology.The
ReleaseConditionDialogPropstype has been correctly updated to useDeploymentVersionConditioninstead ofReleaseConditionfor both theconditionprop and theonChangecallback signature.
64-65: State variable type updated for consistency.The local state variable
localConditionhas been correctly updated to useDeploymentVersionCondition | nullinstead ofReleaseCondition | null.apps/webservice/src/app/[workspaceSlug]/(app)/_components/release/condition/ComparisonConditionRender.tsx (13)
1-4: Type import updated for consistency.Import has been updated from
ReleaseConditiontoDeploymentVersionConditionas part of the terminology refactoring.
35-37: Condition and operator types updated.Types have been updated from
ReleaseFilterTypeandReleaseOperatortoDeploymentVersionConditionTypeandDeploymentVersionOperatorto align with the new terminology.
47-49: Operator type updated in setOperator function.The parameter type for
setOperatorhas been correctly updated to useDeploymentVersionOperatorinstead ofReleaseOperator.
51-54: Condition type updated in updateCondition function.The parameter types for
updateConditionhave been correctly updated to useDeploymentVersionConditioninstead ofReleaseCondition.
62-62: Condition type updated in addCondition function.The parameter type for
addConditionhas been correctly updated to useDeploymentVersionConditioninstead ofReleaseCondition.
79-81: Condition and operator types updated.The types used to create a new comparison condition have been correctly updated to use the new terminology.
114-116: Condition and operator types updated.The types used to create a new negated comparison condition have been correctly updated to use the new terminology.
174-179: Dropdown menu values updated.The
SelectItemvalues have been updated to useDeploymentVersionOperatorenum values instead ofReleaseOperator.
276-278: Condition type and operator updated for metadata.The condition type and operator have been updated to use the new terminology when creating a new metadata condition.
288-289: Condition type updated for created at.The condition type has been updated to use the new terminology when creating a new created at condition.
299-300: Condition type updated for version.The condition type has been updated to use the new terminology when creating a new version condition.
311-315: Condition type and operator updated for filter group.The condition type and operator have been updated to use the new terminology when creating a new filter group condition.
325-329: Condition type and operator updated for not group.The condition type and operator have been updated to use the new terminology when creating a new not group condition.
packages/job-dispatch/src/release-job-trigger.ts (9)
12-12: Import updated to use the new terminology.The import statement has been correctly updated to use
DeploymentVersionStatusfrom the validators package, aligning with the shift from "release" to "deployment version" terminology.
33-33: Property and method renamed correctly.The property
releaseIdshas been properly renamed toversionIds, and the methodreleases()toversions(). This maintains consistency with the deployment version terminology change.Also applies to: 73-75
81-82: Where condition updated correctly.The condition in the
_where()method has been properly updated to check forversionIdsinstead ofreleaseIdsand references the correct schema field.
105-118: Version subquery method renamed and updated correctly.The method
_releaseSubQuery()has been renamed to_versionSubQuery(), and its internals have been updated accordingly:
- Changed field selection from
versiontotag- Updated status check to use
DeploymentVersionStatus.Ready- Updated alias from "release" to "version"
These changes are consistent with the deployment version terminology refactoring.
121-136: Variable names and conditions updated in _values method.The variable names and conditional logic have been appropriately updated to use version terminology instead of release terminology. All references to the subquery and join conditions are using the correct nomenclature.
138-144: Variables and parameters renamed in query result processing.The variable
releaseshas been correctly renamed toversions, and the parameter in the flatMap function has been updated accordingly. This ensures consistency in the terminology change.
176-176: Version ID reference properly updated.The property access path for retrieving the version ID has been updated to use the new structure (
v.version.idinstead ofv.release.id).
184-213: Version references updated in insert method.All references to releases have been correctly updated to use version terminology in the insert method, including variable names and property access paths.
1-238: Overall assessment of terminology refactoring.The changes made in this file effectively implement the transition from "release" to "deployment version" terminology. The renaming is consistent throughout the class implementation, including method names, property names, and logic. This aligns well with the broader refactoring effort described in the PR summary.
A few minor instances of the old terminology remain (e.g., in type definitions and schema references), but these may require coordination with changes in other files in the codebase.
🧰 Tools
🪛 Biome (1.9.4)
[error] 53-53: Do not add then to a class.
(lint/suspicious/noThenProperty)
packages/db/drizzle/0078_wandering_morph.sql (1)
1-2: SQL migration adds new enum values aligned with deployment version terminology.This migration adds two new values to the
release_job_trigger_typeenum: 'new_version' and 'version_updated', which aligns with the PR's objective of transitioning from "release" to "deployment version" terminology.packages/api/src/router/version-metadata-keys.ts (2)
27-28: Field name updated to match new terminology.The join condition now correctly uses
versionIdinstead ofreleaseId, aligning with the deployment version refactoring objective.
55-56: Field name updated to match new terminology.The join condition now correctly uses
versionIdinstead ofreleaseId, maintaining consistency with the first instance of this change and the overall deployment version refactoring.packages/db/src/schema/index.ts (2)
7-7: Module export updated to reflect new terminology.The export has been updated from "release.js" to "deployment-version.js", aligning with the PR's objective to refactor release terminology.
24-24: Added export for release job trigger module.New export for "release-job-trigger.js" has been added, which complements the enum additions in the SQL migration file and likely supports the terminology transition.
packages/validators/src/releases/index.ts (2)
3-7: Enum renamed to match new terminology.The
ReleaseStatusenum has been renamed toDeploymentVersionStatuswhile maintaining the same values, which is consistent with the PR's objective.
9-9: Type renamed to match new terminology.The corresponding type has been updated from
ReleaseStatusTypetoDeploymentVersionStatusType, ensuring consistency with the renamed enum.apps/webservice/src/app/api/v1/releases/[releaseId]/openapi.ts (1)
3-3: Terminology updated from "Release" to "Deployment Version"The import statement and enum usage have been updated to use
DeploymentVersionStatusinstead of the previousReleaseStatus. This change maintains the API functionality while aligning with the new terminology.Also applies to: 40-40
packages/api/src/router/resource-stats.ts (1)
107-107: Data structure improved by nesting version within deployment objectThe response structure has been improved to include the deployment version information as a nested property of the deployment object rather than a separate field. This provides a more logical data hierarchy.
packages/api/src/router/deployment.ts (2)
279-280: Renamed "release" to "version" for consistencyField name changed from
releasetoversionto align with the deployment version terminology change throughout the codebase.
575-576: Renamed "release" to "version" for consistencyField name changed from
releasetoversionin the nested object to align with the deployment version terminology change throughout the codebase.packages/api/src/router/environment-policy.ts (2)
25-25: Updated import name to reflect terminology changeImport statement updated to use
handleEnvironmentPolicyVersionChannelUpdateinstead of the previous release-focused naming. This change aligns with the broader terminology refactoring.
338-342: Updated function call to use new function nameFunction call updated to match the renamed function
handleEnvironmentPolicyVersionChannelUpdate. The parameters remain unchanged, maintaining the existing functionality while using the new terminology.packages/db/src/schema/release-job-trigger.ts (5)
1-10: Schema import structure looks organizedThe imports are well-structured, properly separating database ORM imports from schema references. The imported modules provide all necessary components for defining database entities and relationships.
11-22: Comprehensive enum definition for job trigger typesThe enum values are well-documented with comments explaining each trigger case. This makes the code more maintainable and helps other developers understand when each trigger type is used.
24-50: Well-structured table definition with appropriate constraintsThe table definition is clean with:
- Proper primary key configuration
- Appropriate NOT NULL constraints
- Correct foreign key references with cascade delete behavior where needed
- Clear field naming consistent with database conventions
The unique constraint on
jobIdensures each job can only have one trigger, which seems intentional.
52-56: Type exports provide good TypeScript integrationThe exported types leverage Drizzle's inference capabilities to ensure type safety when working with database records.
57-69: Relations are properly defined for joinsThe relations definition correctly maps the foreign key relationships, which will enable efficient joins when querying related data.
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/ApprovalDialog.tsx (7)
22-24: Property renamed from release to deploymentVersionThe prop type has been updated to use
deploymentVersioninstead ofreleasewithtagreplacingversion, aligning with the broader renaming effort in the codebase.
27-27: Destructuring updated to use new prop nameThe function parameter destructuring correctly uses the renamed prop.
34-38: API endpoint path and parameters updatedThe query invalidation path has been updated from
statusByReleasePolicyIdtostatusByVersionPolicyIdalong with changing the parameter fromreleaseIdtoversionId.
41-42: Reference to deploymentId updatedThe reference to
deploymentVersion.deploymentIdis correctly updated.
45-45: Added variable for clarityCreating a dedicated variable for
versionIdimproves readability.
48-48: Mutation parameter updatedThe mutation correctly uses
versionIdinstead ofreleaseId.
54-54: Consistent mutation parameter updateThe reject mutation also correctly uses
versionId.packages/job-dispatch/src/__test__/job-variables-deployment.test.ts (5)
6-6: Import updated to use DeploymentVersionStatusThe import has been correctly updated to use
DeploymentVersionStatusinstead ofReleaseStatus.
48-48: Job trigger type updatedThe mock job trigger type has been updated from "new_release" to "new_version" to match the schema changes.
77-77: Property renamed from version to tagThe
versionproperty has been updated totagin the deploymentVersion object to align with the schema changes.
79-79: Status enum updatedThe status now uses
DeploymentVersionStatus.Readyinstead ofReleaseStatus.Ready.
139-145:❓ Verification inconclusive
Function naming inconsistency
The function being tested is still named
determineVariablesForReleaseJobwhile the codebase is moving away from "release" terminology. This should be updated for consistency, though it's not part of the current changes.
🏁 Script executed:
#!/bin/bash # Check if the function has been renamed in the implementation file echo "Checking for function name in implementation file..." rg "determineVariablesForReleaseJob" ../job-variables-deployment/job-variables-deployment.js -A 1Length of output: 308
I'll generate a new verification script to search the entire repository for occurrences of the function name. This should help determine whether the implementation has been renamed or moved to a different file.
🏁 Script executed:
#!/bin/bash echo "Searching entire repository for occurrences of 'determineVariablesForReleaseJob'" rg "determineVariablesForReleaseJob" -n .Length of output: 2058
Attention: Verify Function Naming Consistency
The function is still exported as
determineVariablesForReleaseJob(e.g., inpackages/job-dispatch/src/job-variables-deployment/job-variables-deployment.ts) and is referenced similarly throughout the tests. Since the codebase is moving away from “release” terminology, please verify if a renaming is planned to align with the updated naming conventions—even though this isn’t part of the current changes.packages/job-dispatch/src/environment-creation.ts (7)
20-32: Variable renamed from releaseChannels to versionChannelsThe query variable has been appropriately renamed from
releaseChannelstoversionChannels, matching the pattern of replacing "release" terminology with "version" terminology.
33-33: Null check updated for renamed variableThe null check has been properly updated to use the renamed variable.
35-35: Destructuring updated for renamed variableThe destructuring assignment correctly references the renamed variable.
51-71: Promise array renamed from releasePromises to versionPromisesThe array of promises has been renamed from
releasePromisestoversionPromiseswhile maintaining the same functionality.
72-75: Result variable renamed from releases to versionsThe result array from Promise.all has been renamed from
releasestoversions.
83-83: Method call updated from releases to versionsThe method call has been updated from
.releases(releases.map())to.versions(versions.map()).
7-12:❓ Verification inconclusive
Function names still use release terminology
While variable names have been updated to use "version" terminology, the imported function names still use "release" terminology (e.g.,
dispatchReleaseJobTriggers,createReleaseJobTriggers). This is likely part of an ongoing refactoring effort.
🏁 Script executed:
#!/bin/bash # Check if these functions have been updated in their respective files echo "Checking if release-job-trigger.js exists and if it contains renamed functions..." find .. -name "release-job-trigger.js" -type f rg "createReleaseJobTriggers|createVersionJobTriggers" .. -A 1 echo "Checking job-dispatch.js for dispatchReleaseJobTriggers..." find .. -name "job-dispatch.js" -type f rg "dispatchReleaseJobTriggers|dispatchVersionJobTriggers" .. -A 1Length of output: 13413
Notice: Inconsistent Naming – Function Imports Still Use "Release" Terminology
The search confirms that functions such asdispatchReleaseJobTriggersandcreateReleaseJobTriggersremain unchanged across the codebase. In the filepackages/job-dispatch/src/environment-creation.ts(lines 7–12), the imports still reference the legacy "release" terminology even though variable names have already been updated to "version." If this naming is intended as part of the ongoing refactoring effort, please verify that the final design will align all naming conventions. Otherwise, it may be beneficial to refactor these function names for consistency.
- File:
packages/job-dispatch/src/environment-creation.ts
- Imported functions:
dispatchReleaseJobTriggersfrom"./job-dispatch.js"createReleaseJobTriggersfrom"./release-job-trigger.js"packages/job-dispatch/src/policies/gradual-rollout.ts (8)
30-31: Variable renaming fromreleasetoversionThe parameter has been correctly renamed from
releasetoversionto align with the deployment version terminology refactoring.
33-33: Updated property access to use new parameter nameCorrectly updated from
release.createdAttoversion.createdAtto match the parameter renaming.
41-42: Updated database query conditionThe condition now correctly uses
versionIdinstead ofreleaseIdwhich aligns with the schema changes.
101-104: Renamed destructured variables for clarityGood renaming of variables to reflect the deployment version terminology:
release_job_trigger→triggerenvironment_policy→policydeployment_version→versionThis improves code readability and maintains consistency with the new terminology.
105-105: Updated null check to use renamed variableThe conditional check has been properly updated to use
policyinstead ofenvironment_policy.
107-108: Updated function call with renamed parametersThe call to
getRolloutStartnow correctly passesversionandpolicyinstead ofreleaseandenvironment_policy.
112-115: Updated parameters in function callThe parameters in the
isReleaseJobTriggerInRolloutWindowcall have been correctly updated to use the renamed variables.
117-117: Updated return statement with renamed variableCorrectly updated to return
triggerinstead ofrelease_job_trigger.packages/api/src/router/environment-approval.ts (16)
4-11: Improved imports organizationThe imports have been reorganized and the
inArrayfunction has been added, which will be used later in the code. This is a good practice for maintainability.
24-24: Renamed router method to reflect version terminologyThe router method has been correctly renamed from
byReleaseIdtobyDeploymentVersionIdto align with the new terminology.
29-29: Updated authorization check to use deployment versionThe authorization check now correctly uses
type: "deploymentVersion"andinput.versionId.
33-33: Updated input parameter nameThe input parameter has been renamed from
releaseIdtoversionId.
55-55: Updated database query conditionThe query condition now correctly uses
environmentPolicyApproval.versionIdinstead ofreleaseId.
75-75: Updated authorization check in approve procedureThe authorization check now correctly uses
type: "deploymentVersion"andinput.versionId.
78-78: Updated input schema for approve procedureThe input schema for the approve procedure now correctly uses
versionIdinstead ofreleaseId.
88-89: Updated database query condition in approve procedureThe query condition in the approve procedure now correctly uses
versionIdinstead ofreleaseId.
122-123: Updated join condition in approve procedureThe join condition now correctly uses
deploymentVersion.idinstead of the previousrelease.id.
137-137: Updated authorization check in reject procedureThe authorization check in the reject procedure now correctly uses
type: "deploymentVersion"andinput.versionId.
140-140: Updated input schema for reject procedureThe input schema for the reject procedure now correctly uses
versionIdinstead ofreleaseId.
150-151: Updated database query condition in reject procedureThe query condition in the reject procedure now correctly uses
versionIdinstead ofreleaseId.
185-185: Renamed router methodThe router method has been correctly renamed from
statusByReleasePolicyIdtostatusByVersionPolicyId.
190-190: Updated authorization check in statusByVersionPolicyId procedureThe authorization check now correctly uses
type: "deploymentVersion"andinput.versionId.
193-193: Updated input schema for statusByVersionPolicyId procedureThe input schema now correctly uses
versionIdinstead ofreleaseId.
201-202: Updated database query condition in statusByVersionPolicyId procedureThe query condition now correctly uses
versionIdinstead ofreleaseId.packages/job-dispatch/src/resource/dispatch-resource.ts (7)
33-33: Renamed function to reflect version terminologyThe function has been correctly renamed from
getEnvironmentWithReleaseChannelstogetEnvironmentWithVersionChannelsto align with the deployment version terminology refactoring.
62-62: Updated function call to use the renamed functionThe function call now correctly uses the renamed
getEnvironmentWithVersionChannelsfunction.
71-71: Renamed variable to reflect version terminologyThe variable has been renamed from
deploymentsWithReleaseFiltertodeploymentsWithVersionSelectorto align with the new terminology.
80-82: Updated log message to use version terminologyThe log message has been updated to refer to "versions" instead of "releases", maintaining consistency with the terminology changes.
83-100: Renamed variable to reflect version terminologyThe variable has been renamed from
releasePromisestoversionPromisesto align with the new terminology.
102-107: Updated variable name and conditionVariable renamed from
releasestoversionsand the condition now checks for the length of versions array instead of releases.
114-115: Updated method call to use versions instead of releasesThe method call now correctly uses
.versions(versions.map((v) => v.id))instead of the previous.releases(releases.map((r) => r.id)).packages/api/src/router/job.ts (19)
70-71: Updated type name in function parametersThe parameter type has been changed from
releasetodeploymentVersionto align with the new terminology.
78-78: Updated type name for dependency parameterThe parameter type has been changed from
release_dependencytoversion_dependencyto align with the new terminology.
106-109: Updated object structure with deployment versionThe object now correctly uses
deploymentVersionproperty instead ofrelease, maintaining the same structure but using the new terminology.
111-116: Renamed dependencies propertyThe property has been renamed from
releaseDependenciestoversionDependenciesand the related check fromrelease_dependencytoversion_dependency.
125-128: Updated function parametersThe parameters passed to
getRolloutStarthave been updated to useversionrelated names:
versionIdinstead ofreleaseIdversionCreatedAtinstead ofreleaseCreatedAt
198-202: Updated object mapping in list procedureThe object mapping now correctly uses
versionproperty instead ofrelease, maintaining the same structure but using the new terminology.
387-387: Renamed router method to use deployment version terminologyThe router method has been correctly renamed from
byReleaseIdtobyDeploymentVersionId.
392-392: Updated authorization check to use deployment versionThe authorization check now correctly uses
type: "deploymentVersion"andinput.versionId.
396-396: Updated input parameter nameThe input parameter has been renamed from
releaseIdtoversionId.
421-422: Updated query condition in byDeploymentVersionId procedureThe query condition now correctly uses
deploymentVersion.idinstead of the previousrelease.id.
432-433: Updated property mapping in query resultThe property mapping now correctly uses
deploymentVersioninstead of likely the previousrelease.
438-438: Renamed router methodThe router method has been correctly renamed from
byReleaseAndEnvironmentIdtobyVersionAndEnvironmentId.
441-442: Updated input parameter nameThe input parameter has been renamed from
releaseIdtoversionId.
463-465: Updated query condition in byVersionAndEnvironmentId procedureThe query condition now correctly uses
versionIdinstead ofreleaseId.
532-533: Updated property mapping in byId procedureThe property mapping now correctly uses
deploymentVersioninstead of likely the previousrelease.
543-547: Updated function parameters in rolloutDateFromReleaseJobTriggerThe function parameters have been updated to align with the version terminology:
versionIdinstead ofreleaseIdversionCreatedAtinstead ofreleaseCreatedAt
554-557: Updated parameter usage in getRolloutDateForReleaseJobTrigger callThe parameter usage in the function call has been updated to use the renamed parameters:
- Concatenating
versionIdinstead of likelyreleaseId- Passing
versionCreatedAtinstead ofreleaseCreatedAt
518-520: Updated join conditions for version dependencyThe join conditions have been updated to use
versionDependencytable and column names instead of the previousreleaseDependency.
525-526: Updated join condition with deployment nameThe join condition now correctly uses
versionDependency.deploymentIdinstead of likely the previousreleaseDependency.deploymentId.packages/job-dispatch/src/policy-create.ts (1)
47-47: Consistent terminology refactoring.The change from
releaseIdtoversionIdis consistent with the rest of the codebase refactoring, where "release" terminology has been replaced with "deployment version" throughout the application. The field is correctly mapped to accessp.deployment_version.id.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/environments/[environmentId]/resources/EnvironmentResourcesTable.tsx (1)
93-95: Refactored version display matches new data structure.This change aligns with the PR objective of replacing "release" terminology with "deployment version" terminology. The new structure correctly accesses the version tag through the deployment object hierarchy.
packages/job-dispatch/src/policies/manual-approval.ts (1)
39-40: Consistent field naming in join condition.The change from
schema.environmentPolicyApproval.releaseIdtoschema.environmentPolicyApproval.versionIdis consistent with the broader refactoring effort across the codebase. This join condition now properly uses the updated field name while maintaining the same logical relationship in the query.packages/job-dispatch/src/policies/release-sequencing.ts (1)
75-75: Updated sort key from version to tag.The change from
rjt.deployment_version.versiontorjt.deployment_version.tagaligns with the PR objective of standardizing deployment version terminology. The sorting logic maintains the same behavior, first sorting by creation date and then using the tag as a lexicographical tiebreaker.apps/jobs/src/policy-checker/index.ts (1)
43-45: Schema join condition updated correctlyThe join condition between
environmentPolicyApprovalandreleaseJobTriggertables has been updated to useversionIdconsistently, aligning with the deployment version terminology refactoring.packages/job-dispatch/src/policies/release-string-check.ts (1)
17-17: Function name refactored for clarityThe function has been renamed from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicy, which better reflects its purpose while aligning with the "deployment version" terminology refactoring.packages/db/drizzle/meta/_journal.json (1)
550-557: Migration entry added for schema changesA new migration entry has been added to track the database schema changes required for the terminology refactoring.
apps/webservice/src/app/[workspaceSlug]/(app)/resources/(raw)/[resourceId]/deployments/ResourceDeploymentRow.tsx (1)
87-87: Updated property access path for version informationThe component now accesses version information through
data?.[0]?.version.taginstead ofdata?.[0]?.release.version, consistent with the deployment version terminology refactoring.apps/webservice/src/app/api/v1/releases/openapi.ts (2)
3-3: Import updated correctly for terminology change.The import has been correctly updated from
ReleaseStatustoDeploymentVersionStatusto maintain consistency with the broader refactoring from "release" to "deployment version" terminology.
34-34: Usage updated consistently with import change.The enum reference has been appropriately updated to use
DeploymentVersionStatusin the OpenAPI specification, ensuring consistency with the updated import.apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobProperties.tsx (2)
52-52: Property path correctly updated to use new terminology.The reference to
job.release.deployment.namehas been properly updated tojob.deploymentVersion.deployment.name, maintaining consistency with the broader deployment version terminology refactoring.
56-56: UI label and property access updated for terminology consistency.The label has been changed from "Release" to "Version" and the property access has been updated from
job.release.nametojob.deploymentVersion.name, ensuring UI consistency with the new terminology.Also applies to: 58-58
packages/db/src/schema/release-channel-relations.ts (1)
3-3: Import source updated to reflect new file structure.The import path for
deploymentVersionChannelhas been updated from./release.jsto./deployment-version.js, correctly reflecting the restructured file organization while maintaining the same functionality.packages/db/src/schema/resource.ts (1)
54-54: Import path updated to use more specific module.The import path for
releaseJobTriggerhas been updated from./release.jsto the more specific./release-job-trigger.js, which better organizes the code by separating concerns while maintaining the same functionality.apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)
44-44: Schema join condition updated correctlyThe join condition for SCHEMA.deploymentVersionMetadata has been updated to use versionId instead of releaseId, which aligns with the broader refactoring to replace "release" terminology with "deployment version".
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/DeployButton.tsx (3)
11-12: Component props updated correctlyThe props have been correctly updated to use
deploymentVersionIdinstead ofreleaseId, which aligns with the broader terminology refactoring.
14-14: Destructured parameter updated correctlyThe destructuring syntax has been properly updated to match the renamed prop.
30-30: API call parameter updated correctlyThe property name in the object passed to
mutateAsynchas been correctly updated fromreleaseIdtoversionId: deploymentVersionId, ensuring proper integration with the updated API.packages/job-dispatch/src/job-failure.ts (1)
51-51: Method call updated correctlyThe method call has been correctly updated from
.releases()to.versions()to align with the terminology changes, while maintaining the same functionality and parameters.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/layout.tsx (3)
40-41: Variable name updated correctlyThe variable name has been correctly updated from
releasetoversion, and the null check has been adjusted accordingly.
43-43: Property reference updated correctlyThe property reference has been properly updated to use
version.deploymentIdinstead ofrelease.deploymentId.
77-77: Display property updated correctlyThe breadcrumb display has been updated to show
version.taginstead ofrelease.version, maintaining the correct visual presentation while using the new property structure.packages/api/src/router/deployment-variable.ts (2)
36-36: Updated policy import aligns with terminology refactoring.This import change from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyis part of the broader initiative to replace "release" terminology with "deployment version".
256-256: Updated policy usage consistent with the import change.The filter is now using
isPassingChannelSelectorPolicyinstead ofisPassingReleaseStringCheckPolicy, maintaining consistency with the import change on line 36. This ensures that the job triggers are filtered using the renamed policy.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/ApprovalCheck.tsx (3)
8-10: Updated prop type fromreleasetodeploymentVersion.The component prop has been updated from
releasetodeploymentVersionwithversionrenamed totag, correctly aligning with the terminology changes across the codebase.
11-15: Updated API query to use version terminology.API query has been modified to use
statusByVersionPolicyIdinstead ofstatusByReleasePolicyIdandversionIdinstead ofreleaseId, ensuring consistency with the new terminology.
52-56: Props passed to ApprovalDialog component updated.The
ApprovalDialogcomponent now receivesdeploymentVersioninstead ofrelease, maintaining consistency with the prop changes in the parent component.packages/db/src/schema/release-channel.ts (1)
4-4: Updated import path to reflect new file name.The import statement has been updated to get
deploymentVersionChannelfrom "./deployment-version.js" instead of "./release.js", correctly aligning with the file renaming that's part of the broader terminology refactoring.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/properties/page.tsx (6)
17-17: Renamed variable fromreleaseIdtoversionId.The destructuring assignment has been updated to rename
releaseIdtoversionId, keeping the variable name consistent with the new terminology.
19-22: Updated API call and null check to use version terminology.The API call has been changed from
release.byIdtoversion.byIdand the null check now verifiesversioninstead ofrelease. The metadata extraction is also updated accordingly.
47-51: Updated condition and display value with version terminology.The condition now compares
version.namewithversion.taginstead ofrelease.namewithrelease.version, and displaysversion.nameinstead ofrelease.name.
55-57: Updated version display using new terminology.The component now displays
version.taginstead ofrelease.version, maintaining consistency with the new terminology.
60-62: Updated date display to use version object.The component now formats and displays
version.createdAtinstead ofrelease.createdAt.
106-108: Updated ConfigEditor value to use version config.The
ConfigEditorcomponent now receivesversion.configinstead ofrelease.configfor its value prop.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx (3)
8-8: Import renamed correctly.The import statement has been updated from
ReleaseDistributionBarCharttoVersionDistributionBarChartas part of the terminology refactoring.
14-14: Variable renamed correctly.The variable has been properly renamed from
showPreviousReleaseDistrotoshowPreviousVersionDistroto align with the new terminology.
27-30: Component and props renamed correctly.The component reference has been updated to
VersionDistributionBarChartand the prop has been renamed toshowPreviousVersionDistro.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/EnvironmentApprovalRow.tsx (3)
9-12: Prop type renamed correctly.The type definition has been properly updated to use
deploymentVersioninstead ofrelease, maintaining the same structure withid,tag, anddeploymentIdproperties.
14-17: Destructured prop renamed properly.The component parameter has been correctly updated to use the renamed prop.
20-23: Dialog component updated correctly.The
ApprovalDialogcomponent now receives the renameddeploymentVersionprop instead ofrelease.packages/job-dispatch/src/deployment-update.ts (3)
16-16: Policy function renamed correctly.The import statement has been updated to reference the renamed policy function
isPassingChannelSelectorPolicy, which was previously likely namedisPassingReleaseStringCheckPolicy.
85-92: Terminology updated consistently.The string identifier has been changed from "new_release" to "new_version" and the filter function has been renamed to
isPassingChannelSelectorPolicyto reflect the shift from release to version terminology.
151-160: Terminology updated consistently in second occurrence.The same changes have been applied to the second occurrence, ensuring consistency throughout the file.
packages/job-dispatch/src/job-creation.ts (2)
113-115: Schema reference renamed properly.The reference has been updated from
schema.releaseDependency.idtoschema.versionDependency.idto align with the new terminology.
150-159: Join operation and conditions updated correctly.The left join operation now references
schema.versionDependencyinstead ofschema.releaseDependency, and the corresponding field references in the conditions have been updated to useversionIdanddeploymentId.packages/api/src/router/resources.ts (2)
28-28: Function import name updated for consistent terminologyThis import has been updated from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyas part of the codebase refactoring to replace "release" terminology with "deployment version" terminology.
777-777: Filter function name updated for consistencyUpdated from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyto align with the refactored function in the imported module. This change matches the terminology transition from "release" to "deployment version" across the codebase.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/page.tsx (4)
21-22: Terminology updated from "release" to "deploymentVersion"Changed variable name and API call to use the new terminology, aligning with the standardized naming convention for deployment versions.
25-25: Changed metadata rendering to use version tagUpdated metadata title to use
deploymentVersion.taginstead ofrelease.version, maintaining functionality while using the new terminology.
31-33: Terminology updated in variable assignments and null checksConsistently updated from
releasetodeploymentVersionin both data fetching and existence checks to maintain codebase terminology consistency.
39-43: Component prop name updated for consistencyUpdated the
ResourceReleaseTablecomponent to receivedeploymentVersionprop instead ofrelease, ensuring proper propagation of the terminology changes throughout the component hierarchy.packages/job-dispatch/src/policies/release-dependency.ts (2)
22-24: Updated database schema references for terminology consistencyChanged from
schema.releaseDependencytoschema.versionDependencyand updated the join condition fromreleaseIdtoversionId, aligning with the database schema changes for consistent terminology.
121-121: Updated field reference for version selectorChanged from
dep.releaseFiltertodep.versionSelectorin the deployment version matching condition, maintaining functionality while using updated terminology.apps/webservice/src/app/[workspaceSlug]/(app)/_components/resources/ReleaseCell.tsx (2)
79-80: Updated prop type name for terminology consistencyChanged the property type in
releaseJobTriggerfromrelease?toversion?, keeping the same underlying type ofPartial<SCHEMA.DeploymentVersion>.
92-94: Updated property access for rendering version tagChanged from accessing
releaseJobTrigger.release?.versiontoreleaseJobTrigger.version?.tag, maintaining the display functionality while using the updated field names.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/EnvironmentNode.tsx (2)
32-40: Props refactored from release to version terminology.The EnvironmentNodeProps type has been updated to use
versionIdandversionTaginstead ofreleaseIdandreleaseVersion, which aligns with the broader refactoring effort to switch from "release" to "deployment version" terminology.
135-146: Version parameter updated in hook call.The
DeploymentVersionChannelCheckcomponent now correctly usesversionTagwith theuseDeploymentVersionChannelhook, aligning with the updated hook signature.apps/webservice/src/app/api/v1/releases/[releaseId]/route.ts (4)
13-13: Policy check function updated to match new terminology.The imported policy check function has been updated from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyto reflect the terminology change.
40-41: Internal variable renamed while preserving API compatibility.The API route parameter
releaseIdis maintained for backward compatibility, but internally it's aliased toversionIdto align with the new terminology.
71-89: Job trigger event and filter updated.The job trigger event has been updated from "release_updated" to "version_updated", and the related filter and versions method calls have been updated accordingly.
94-97: Error message updated to reflect new terminology.The error message has been updated from "Failed to update release" to "Failed to update version" to maintain consistency with the new terminology.
packages/validators/src/cac/index.ts (3)
3-7: Schema entity renamed from release to version.The validator schema has been updated to use
versioninstead ofreleasewhile keeping the same structure.
9-14: Updated deployment schema to use versions instead of releases.The
deploymentschema now references the renamedversionsarray instead ofreleases.
21-29: Updated cacV1 schema to use versions instead of releases.The
cacV1schema now references the renamedversionsrecord instead ofreleases.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/DeploymentEnvironmentCell.tsx (2)
101-114: Updated Release component props.The Release component props have been updated to use
versionIdandversionTaginstead of release-related props.
123-154: Updated ApprovalDialog props and references.The ApprovalDialog component now receives
deploymentVersioninstead ofrelease, and references torelease.approvalhave been updated todeploymentVersion.approval.apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/drawer/JobDrawer.tsx (2)
45-50: Property path update correctly switches to deploymentVersion structure.The hook parameters have been properly updated to use the
deploymentVersionobject properties. This aligns with the PR goal of replacing "release" terminology with "deployment version" terminology.
74-79: Props consistently updated to use deploymentVersion pattern.The JobDropdownMenu component props have been appropriately updated to use the new deploymentVersion structure, maintaining consistency across the component tree.
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/TableCells.tsx (4)
122-143: Component renamed and props updated to follow deployment version naming convention.The component has been successfully renamed from
ReleasetoDeploymentVersionwith its props updated accordingly (releaseId→versionId,version→tag). This maintains the proper data structure while aligning with the new terminology.
145-149: Filter condition correctly references versionId property.The job filter condition has been updated to use the new property name
versionIdin the value field.
198-214: URL path and UI element contents updated for consistency.The Link's href path and display text have been updated to use the
versionIdandtagvariables, ensuring proper navigation and visual consistency.
258-262: DropdownMenu prop structure updated to follow new pattern.The ReleaseDropdownMenu component prop has been updated from
release={{ id: releaseId, name }}todeploymentVersion={{ id: versionId, name }}, maintaining the proper object structure.packages/db/src/schema/job.ts (2)
47-50: Import statements properly updated to reference new module paths.The imports have been correctly updated to reference the new module paths, maintaining proper dependencies after the refactoring.
259-269: buildVersionCondition function updated to use tag property.All references to
deploymentVersion.versionhave been correctly changed todeploymentVersion.tagacross all comparison operators in the buildVersionCondition function. This ensures that database queries will work properly with the new schema structure.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/channels/CreateDeploymentVersionChannelDialog.tsx (4)
3-3: Import type updated to DeploymentVersionCondition.The import has been correctly updated to use the new type name.
34-35: Schema validator import updated.The import for the validation schema has been updated from
releaseConditiontodeploymentVersionCondition.
49-50: Function signature updated to use new type.The getFinalFilter function now correctly accepts the DeploymentVersionCondition type.
55-58: Schema validation updated to use deploymentVersionCondition.The schema object now correctly uses the deploymentVersionCondition validator.
apps/webservice/src/app/api/v1/jobs/[jobId]/route.ts (1)
19-19: Change from 'release' to 'version' terminology is consistent.The refactoring to replace "release" with "version/deployment version" terminology has been implemented correctly throughout this file. The function signature, query conditions, variable names, and property references have all been updated consistently.
Also applies to: 29-29, 104-107, 115-115, 121-122
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowNode.tsx (1)
13-18: Props and API query refactoring looks good.The changes to the component props and API query method are consistent with the terminology shift from "release" to "deploymentVersion". Both the type definition and the query implementation have been updated correctly.
Also applies to: 22-24
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowDiagram.tsx (1)
26-27: Consistent renaming from 'release' to 'deploymentVersion'.The component props, destructured parameters, and internal references have been updated consistently to use "deploymentVersion" instead of "release". All property references are correctly aligned with the new terminology.
Also applies to: 30-30, 36-37, 48-49, 59-62
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionBarChart.tsx (1)
8-11: Component and logic successfully refactored to use 'version' terminology.The component has been renamed from
ReleaseDistributionBarCharttoVersionDistributionBarChart, with corresponding updates to props, variables, and data mapping logic. All references have been consistently updated from "release" to "version".Also applies to: 12-13, 20-23, 26-28
packages/api/src/router/version-deploy.ts (11)
12-12: Policy checker import updated to match new naming convention.The import has been correctly updated from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyto align with the renamed policy function in the job-dispatch package.
19-19: Router name updated to reflect 'version' terminology.The router has been appropriately renamed from
releaseDeployRoutertoversionDeployRouteras part of the consistent terminology change across the codebase.
26-27: Authorization check updated to use 'deploymentVersion' type.The authorization resource type has been correctly updated from 'release' to 'deploymentVersion' to match the new terminology.
33-33: Input schema parameter renamed from 'releaseId' to 'versionId'.The parameter name has been appropriately updated in the input validation schema to maintain consistency with the new terminology.
44-44: Method call updated from 'releases' to 'versions'.The builder method has been correctly updated to use the new 'versions' method name instead of 'releases'.
48-48: Filter policy updated to use new policy checker.The policy checker used in the filter has been correctly updated to
isPassingChannelSelectorPolicyto match the renamed function.
73-74: Authorization check updated in toResource procedure.The authorization resource type has been correctly updated from 'release' to 'deploymentVersion' in the toResource procedure.
80-80: Input parameter renamed in toResource procedure.The parameter has been appropriately renamed from 'releaseId' to 'versionId' in the input validation schema for the toResource procedure.
103-103: Database query updated to use new schema reference.The database query has been correctly updated to use
SCHEMA.deploymentVersion.idinstead of the previous reference.
120-120: Builder method updated in toResource procedure.The builder method call has been correctly updated to use
.versions([rel.id])instead of the previous method name.
125-125: Filter policy updated in toResource procedure.The policy checker in the toResource procedure has been correctly updated to use
isPassingChannelSelectorPolicy.packages/db/src/schema/environment.ts (3)
26-26: Import path updated to match renamed file.The import has been correctly updated to import from
./deployment-version.jsinstead of./release.js, reflecting the renamed source file.
262-265: Field renamed while preserving DB column name.The
releaseIdfield has been renamed toversionIdwhile maintaining the same database column name ("release_id") for backward compatibility. This approach preserves the database schema while updating the code terminology.
272-272: Unique index updated to use renamed field.The unique index definition has been correctly updated to use
t.versionIdinstead oft.releaseId, ensuring the index references the renamed field.apps/webservice/src/app/api/v1/config/route.ts (13)
25-25: Updated policy checker import.The import has been correctly updated from
isPassingReleaseStringCheckPolicytoisPassingChannelSelectorPolicyto align with the renamed policy function.
130-131: Function renamed to reflect version terminology.The function has been appropriately renamed from
upsertReleasestoupsertVersions, and the condition now properly checks forconfig.versionsinstead ofconfig.releases.
133-136: Variable names updated in mapping operation.The variable
releaseInfohas been renamed toversionInfo, and the destructuring now correctly extractstaginstead ofversionto match the new terminology.
139-144: Object structure updated for version data.The name derivation and returned object structure have been updated to match the new terminology, now using
versioninstead ofreleaseandtaginstead ofversion.
148-151: Variable naming aligned with version terminology.The variables have been appropriately renamed to align with the version terminology, maintaining consistency throughout the function.
177-180: Renamed property in groupBy mapping result.The property has been correctly renamed from
releasestoversionsin the mapping result to maintain consistency.
184-196: Variable names and conditional checks updated.The filtering operation has been updated to use
newVersionsinstead ofnewReleases, and the condition now properly checks forr.tag === version.taginstead of the previous version comparison.
198-208: Insert operation variable names updated.The variables used in the insert operation have been appropriately renamed from
releaseInsertstoversionInserts, and the object structure has been updated to match the new terminology.
211-214: Database operations updated for version terminology.The database insert operation and returned variable have been updated to match the new terminology, using
versionsinstead ofreleases.
216-233: Metadata handling updated for versions.The metadata handling has been appropriately updated to use
versionMetadataInsertsandversionIdinstead of their release counterparts, and the condition has been updated to check for version tag matches.
236-239: Metadata insertion updated to use version schema.The metadata insertion check and operation have been updated to use the
deploymentVersionMetadataschema instead of the previous schema.
241-244: Job trigger creation updated for version terminology.The job trigger creation has been updated to use "new_version" as the type,
isPassingChannelSelectorPolicyas the filter, and.versions()instead of.releases(), maintaining consistency with the overall refactoring.
295-295: Function call updated in PATCH handler.The function call in the PATCH handler has been correctly updated to use
upsertVersionsinstead ofupsertReleases.apps/webservice/src/app/[workspaceSlug]/(app)/_hooks/channel/useDeploymentVersionChannel.ts (5)
1-1: Updated import type for conditions.The import type has been correctly updated from
ReleaseConditiontoDeploymentVersionConditionto align with the renamed type definitions.
9-9: Updated enum import for condition types.The import has been correctly updated from
ReleaseFilterTypetoDeploymentVersionConditionTypeto match the renamed enum.
16-16: Function parameter renamed to match version terminology.The parameter has been appropriately renamed from
releaseVersiontoversionTagto maintain consistency with the new terminology throughout the codebase.
29-33: Updated version filter configuration.The version filter has been correctly updated to use
DeploymentVersionConditiontype,DeploymentVersionConditionType.Versionfor the type property, andversionTagfor the value property, aligning with the new terminology.
35-35: Updated release filter type annotation.The type annotation for the release filter has been correctly updated to use
DeploymentVersionConditioninstead of the previous type.packages/api/src/router/environment.ts (3)
60-70: Consistent renaming of release channel properties to deployment version channel.The keys in the select clause have been properly renamed from
releaseChannel*todeploymentVersionChannel*to align with the new terminology. This maintains consistency with the schema changes inpackages/db/schema.
95-98: Proper join condition update following renamed fields.The join condition has been correctly updated to use the new field name
deploymentVersionChannelPolicyIdinstead of the oldreleaseChannelPolicyId.
114-121: Consistent adoption of the new property names in data mapping.The property references in the chain operations have been properly updated to use the new
deploymentVersionChannel*naming convention, including the renamedversionSelectorfield (previouslyfilter).apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/page.tsx (4)
27-28: Variable naming updated to reflect new terminology.Correctly changed from
releasetodeploymentVersionto maintain consistent terminology across the codebase.
31-32: Property reference updated from version to tag.Properly changed from
release.versiontodeploymentVersion.tagto align with the schema changes.
37-45: API call and variable naming consistently updated.The Promise variable name and API call have been correctly updated to use the new terminology, along with proper destructuring in the Promise.all result.
69-70: Component prop name updated.The prop name for FlowDiagram has been appropriately changed from
releasetodeploymentVersion.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/checks/_components/flow-diagram/FlowPolicyNode.tsx (6)
18-19: Interface property renamed to match new terminology.The property in the PolicyNodeProps type has been correctly updated from
releasetodeploymentVersion.
26-27: Function parameter destructuring updated.The destructured parameter has been properly renamed from
releasetodeploymentVersionin the MinSuccessCheck component.
29-31: API endpoint and parameter name updated.The API call has been correctly changed from
byReleaseIdtobyDeploymentVersionIdand the parameter fromreleaseIdtoversionId.
74-76: API endpoint and parameter names updated for approval status.The API endpoint has been properly renamed from
statusByReleasePolicyIdtostatusByVersionPolicyIdand the parameters have been updated accordingly.
80-82: Property reference updated in logic determining the start date.References to
release.createdAthave been correctly changed todeploymentVersion.createdAt.
164-168: Component prop updated for ApprovalCheck.The prop passed to ApprovalCheck has been correctly renamed from
releasetodeploymentVersion.apps/webservice/src/app/[workspaceSlug]/(app)/_components/channel/drawer/Overview.tsx (6)
2-3: Import type updated to follow new naming convention.The import type has been correctly changed from
ReleaseConditiontoDeploymentVersionCondition.
29-30: Import name updated to match new terminology.The import has been properly changed from
releaseConditiontodeploymentVersionCondition.
45-46: Function parameter type updated.The parameter type for
getFinalFilterhas been correctly changed fromReleaseConditiontoDeploymentVersionCondition.
53-54: Parameter type updated in function signature.The parameter type for
filteringetReleaseFilterUrlhas been correctly updated toDeploymentVersionCondition.
71-72: Schema validator updated to use new condition type.The schema definition correctly uses
deploymentVersionConditioninstead ofreleaseCondition.
77-79: Function parameter and return type updated.Both the parameter and return type for
getFilterhave been properly updated toDeploymentVersionCondition.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/deployments/environment-cell/ReleaseInfo.tsx (5)
57-58: Props updated to use version-based terminologyThe component props have been refactored to use
versionIdandtaginstead ofreleaseIdandversion, consistent with the PR objective of replacing release terminology with deployment version terminology.Also applies to: 69-70
78-80: API query method renamed to match new terminologyThe API query has been correctly updated from
byReleaseAndEnvironmentIdtobyVersionAndEnvironmentIdwith appropriate parameters.
106-111: URL construction updated to follow naming convention changesThe URL construction has been properly updated to use the structured URL pattern with the new
versionIdparameter.
125-125: UI display updated to show tag instead of versionThe display elements have been updated to show
taginstead ofversion, maintaining UI consistency with the new terminology.Also applies to: 129-129
161-165: ReleaseDropdownMenu prop updated to use deploymentVersion objectThe component now receives a
deploymentVersionobject containing theversionIdinstead of the previousreleaseobject, consistent with the terminology changes across the application.apps/webservice/src/app/[workspaceSlug]/(app)/_components/job/JobDropdownMenu.tsx (6)
89-89: API invalidation call updated to use deploymentVersion terminologyThe API invalidation call has been correctly updated from
byReleaseIdtobyDeploymentVersionId.
168-182: ForceReleaseResourceDialog props renamed to use deploymentVersionThe component now uses
deploymentVersioncontainingidandtagproperties instead ofreleasewithidandversionproperties, making it consistent with the terminology changes throughout the application.
215-216: API mutation parameter renamed from releaseId to versionIdThe API parameter has been correctly updated to use
versionIdinstead ofreleaseIdwhen calling the mutation.
235-239: RedeployReleaseDialog props updated to use deploymentVersionThe component props have been refactored to use
deploymentVersioninstead ofrelease, maintaining consistency with the terminology changes.
269-270: Redeploy mutation parameter updated to use versionIdThe API parameter has been correctly updated to use
versionIdinstead ofreleaseIdwhen calling the redeploy mutation.
284-292: JobDropdownMenu props updated to use deploymentVersionThe component now accepts
deploymentVersioninstead ofreleaseas a prop, maintaining consistency with the terminology changes across the application.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/DeploymentPageContent.tsx (7)
5-6: Updated import types to use DeploymentVersion terminologyImport statements have been correctly updated to use
DeploymentVersionStatusTypeandDeploymentVersionStatusinstead of the release-based types.Also applies to: 41-42
51-52: Component name updated to reflect terminology changeThe component import has been updated to reference
VersionDistributionPopoverwhile maintaining the legacy import nameReleaseDistributionGraphPopoverfor compatibility.
61-86: StatusIcon component updated to use DeploymentVersionStatusThe component props and status comparisons have been updated to use
DeploymentVersionStatusTypeandDeploymentVersionStatusenums instead of the previous release-based types.
194-201: API query and variable names updated to use versions instead of releasesThe API query and associated variables have been renamed from
releasestoversionsto align with the new terminology.
204-208: URL construction updated to use the new naming conventionsThe URL construction has been updated to maintain the correct path structure while using the renamed components.
240-241: Data access updated to use versions data instead of releases dataReferences to
releases.datahave been correctly updated toversions.datato match the variable name changes.Also applies to: 254-255
308-375: Iteration and rendering logic updated to use version terminologyThe mapping and rendering logic has been updated to iterate over
versions.data.itemsand useversion.status,version.id, etc., instead of the release equivalents.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(raw)/releases/[releaseId]/jobs/release-table/ResourceReleaseTable.tsx (5)
46-46: Updated type to use DeploymentVersionId instead of ReleaseIdThe
Triggertype has been updated to referencebyDeploymentVersionIdfrom the API output instead ofbyReleaseId.
52-57: CollapsibleTableRowProps updated to use deploymentVersionThe type definition now uses
deploymentVersionwithid,tag,name, anddeploymentIdproperties instead ofreleasewithversion.
70-73: API query updated to use byDeploymentVersionIdThe API query method has been correctly updated to use
byDeploymentVersionIdinstead ofbyReleaseIdwith the appropriate parameter name.
459-464: ResourceReleaseTableProps type updated for terminology consistencyThe props type definition has been updated to use
deploymentVersionwith the appropriate properties instead ofrelease.
475-477: Job query renamed to use DeploymentVersionIdThe job trigger query has been updated to use
byDeploymentVersionIdwith the appropriateversionIdparameter instead of the previous release-based query.packages/validators/src/releases/conditions/release-condition.ts (10)
13-17: Renamed type aligns with new naming conventions.
The newDeploymentVersionConditiontype effectively replaces the old release-based equivalent. No immediate functional concerns.
19-24: Union type looks correct.
Usingz.unionensures proper schema validation of the various condition subtypes.
26-37: Enum renamed to reflect "DeploymentVersion" context.
All retained operators appear unchanged in usage. No issues foreseen.
39-44: Enum name updated to match new condition type.
Naming is consistent with the rest of the refactoring.
46-48: Default condition retains original logic but references new enum.
Specifically uses the comparison operator "And" as the default. Looks good.
53-56: Renamed condition type usage within isEmptyCondition.
No issues with logic; function remains straightforward.
60-62: isComparisonCondition transition to new naming.
No functional changes; logic still checks for "Comparison" type.
83-85: isMetadataCondition references new "Metadata" enum value.
Refactor matches the renamed type. No concerns.
88-90: isVersionCondition references new "Version" enum.
No issues.
93-95: isCreatedAtCondition references the changed "CreatedAt" enum value.
Implementation is consistent.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx (14)
4-4: Imports updated to use "DeploymentVersion" naming.
This aligns with the broader refactoring but note the forthcoming local type conflict.Also applies to: 18-18, 25-25
36-36: New props interface reflects "DeploymentVersion."
Aside from the naming conflict noted above, the structure is consistent.Also applies to: 39-39
75-77: Component signature renamed.
Transition toDeploymentVersionEnvironmentCellis consistent with the new naming.
89-89: Query references new ID property.
api.deployment.version.blocked.useQuery([deploymentVersion.id])is consistent with the updated approach.
92-93: Approval policy usage updated to "versionPolicyId."
Renaming from release-based to version-based is consistent with the PR theme.
103-103: Version ID now referencesdeploymentVersion.id.
Ensures alignment with the new ID field.
152-152: Rendered component uses "DeploymentVersion" props.
The JSX references tag, name, and createdAt from the new type.Also applies to: 156-157, 159-160
166-166: Status checks updated for "Building" and "Failed."
Matches the newly importedDeploymentVersionStatusenum.Also applies to: 173-173
208-208: ApprovalDialog prop renamed.
The newdeploymentVersionprop is consistent with the rest of the code.
218-220: Tag usage updated to reflect "deploymentVersion.tag."
Properly renamed from the old release-based property.
229-229: Dropdown menu references "deploymentVersion" prop.
Maintains consistency with updated naming.
237-242: New deployment trigger.
<DeployButton>usesdeploymentVersionIdandenvironmentIdprops, aligning with new logic.
246-246: LazyReleaseEnvironmentCell updated props.
Renamed toDeploymentVersionEnvironmentCellProps. Consistent with the changes above.
253-253: Conditional rendering logic references new component name.
RenderingDeploymentVersionEnvironmentCellonce in-view is correct.apps/webservice/src/app/api/v1/releases/route.ts (15)
20-20: Renamed policy check import.
UsingisPassingChannelSelectorPolicyis in line with the new naming convention.
24-24: Import updated to reference "DeploymentVersionStatus."
Clean transition away from the oldReleaseStatus.
30-35: Schema extended to accommodate new optional fields (tag, version).
Combines them withcreateDeploymentVersionschema. No issues.
52-58: Helper function determines version name priority.
Transitions fromname→tag→version. This matches the overall refactor.
60-64: Rejects empty version name with 400 status.
Appropriate validation to ensure a valid value.
67-72: Helper function for obtainingversionTag.
Same fallback logic asgetVersionName, ensuring a consistent naming approach.
73-78: Validation ensures non-emptyversionTag.
Returns 400 if missing, matching the logic for version name.
81-81: Retrieves existing deployment version by tag.
Replacing any references to release-based fields with new "tag."Also applies to: 87-87
92-92: Inserts or updates deployment version with "tag" and "name."
Logic merges existing and new properties.Also applies to: 94-94
98-98: Conflict resolution uses "tag" as part of the unique key.
This is consistent with the updated logic focusing ondeploymentVersion.tag.
116-116: Metadata insertion referencesdepVersion.id.
All references are updated to the "versionId" field.
133-135: Only triggers job creation if status transitions to "Ready."
Checks the prior status to avoid re-triggering.
138-138: Uses new job trigger type "new_version" and references updated policy.
Approach is consistent with the naming convention shift.Also applies to: 141-141
153-153: Log message references "depVersion.id."
Adjusts from "release" to "version," aligning with the global rename.
159-159: Final response returns updated object with "metadata."
Correctly merges the new version entity and its metadata.packages/api/src/router/deployment-version.ts (23)
28-28: Refactor name aligns with correct usage.
This rename from the old policy function name toisPassingChannelSelectorPolicyis consistent with the new channel-based policy naming across the codebase and doesn't appear to introduce any breaking changes.
41-42: Renamed imports match new naming.
Switching todeploymentVersionConditionandDeploymentVersionStatuscorrectly aligns with the new deployment version schema.
46-47: Logical reorganization of routers.
These router imports are updated to reflect the “version” naming convention, maintaining consistency with the broader refactoring.
144-151: Additional left join ensures policy attached.
TheseleftJoinoperations integrateenvironmentPolicydetails without excluding records that lack a matching entry, supporting more comprehensive policy-based logic.
167-167: Refined mapping approach.
Collecting and filteringenvironment_policyensures only valid policies are included in the final array.
208-208: Filter parameter updated.
UsingdeploymentVersionCondition.optional()replaces the older release-based filter, aligning with the newly introduced version-based condition logic.
222-222: Condition array usage.
Combining[deploymentIdCheck, versionSelectorCheck]then filtering out non-present values is a concise way to build conditional queries dynamically.
233-234: Joins updated for version dependency.
ReferencingSCHEMA.versionDependencyinstead ofreleaseDependencypreserves relationships to the new table structure.
238-238: Using tag ordering.
Sorting bydesc(SCHEMA.deploymentVersion.tag)is consistent with the move away from the old version-based field.
247-247: Mapping versionDependencies.
Renaming and grouping the associated dependencies underversionDependenciesis consistent with the new deployment version approach.
317-317: New deploy route.
Exposingdeploy: versionDeployRouterrepresents a clear addition for handling deployment version–specific routing.
331-333: Constructing versionDeps references.
Copying each dependency’s data and assigningversionIdensures proper linkage to the version being created.
339-340: Conditional insertion of dependencies.
InsertingversionDepsonly when non-empty is a clean approach for optional version dependencies.
345-349: New filter usage for channel-based selection.
ApplyingisPassingChannelSelectorPolicybefore job triggers are dispatched manages environment-channel rules at creation time.
367-370: Updated job trigger creation.
Replacing references to older release triggers with"version_updated"and channel-based filtering aligns with the new version naming.
450-450: Safe destructuring approach.
Indexingv[0]!after grouping implies at least one record exists per group, making the non-null assertion purposeful.
455-455: Version channels retrieval.
Accurately renamingreleaseChannelstoversionChannelsreflects the fundamental change from releases to versions.
466-466: Destructuring environment data.
Extractingversion,environment, andenvironmentPolicyin a single statement keeps the code organized and readable.
475-475: Matching version logic.
Determining a match through the channel’sversionSelectorensures that only versions meeting policy constraints pass.
491-493: Blocked environment logic.
Returning an object with{ versionId, environmentId, deploymentVersionChannelId }when no matching version exists helps identify resources that remain blocked.
507-507: Refined input schema.
Switching the schema fields to referenceversionIdclarifies that we’re handling deployment versions rather than releases.
516-516: Aligned identifier usage.
Usingid: input.versionIdensures we consistently apply the newversionIdnaming throughout the code.
536-536: Filtering on versionId.
Revising thewhereclause to matchSCHEMA.releaseJobTrigger.versionIdis consistent with the new naming approach.packages/db/src/schema/deployment-version.ts (24)
6-6: Imported condition interface.
ImportingDeploymentVersionConditionsupports the version-based condition checks introduced throughout the codebase.
7-7: New import for advanced usage.
Bringing inInferSelectModelandSQLfromdrizzle-ormis helpful for typed query building and model inferring.
41-44: Refactored enumerations & condition imports.
IntroducingdeploymentVersionCondition,DeploymentVersionConditionType,DeploymentVersionOperator, andDeploymentVersionStatusunderscores the migration from release-based to version-based logic.
60-60: Updated version selector.
DefiningversionSelectorasDeploymentVersionCondition | nullreplaces the older release paradigm with version-based filtering.
71-71: Schema creation with condition.
ApplyingdeploymentVersionConditionensures any insertedversionSelectorfields are validated in line with the new version-based model.
76-91: Renamed dependency schema aligns with version-based approach.
Transitioning the table name toversionDependencyand referencingdeploymentVersion.idfor dependencies adheres to the updated schema design.
93-93: Exporting typed model.
Providing aVersionDependencytype viaInferSelectModelimproves code clarity and type safety.
95-97: Initializing createVersionDependency.
Building the insert schema for version dependencies ensures thatversionSelectorfollows the correct structure.
99-103: Renamed enum for version status.
AdoptingversionStatusclarifies the permissible states of a deployment version.
110-110:tagfield replaces version.
Shifting the column totagconveys a more descriptive name for the version label.
122-122: Defaulting version status to "ready".
Setting the default status to"ready"ensures newly created versions are considered active by default.
127-127: Updated unique index constraints.
Using(deploymentId, tag)uniquely identifies each version within a deployment.
135-135: Validating tag length.
Enforcing.min(1)prevents empty tags and supports consistent naming conventions.
139-139: Using a typed enum validation.
Applyingz.nativeEnum(DeploymentVersionStatus)ensures this field adheres to recognized version states.
147-148: Including versionDependencies in create schema.
Permitting an array of objects derived fromcreateVersionDependencyallows the code to maintain references to other versions as needed.
158-158: Metadata references updated.
PointingversionIdatdeploymentVersion.idexplicitly links metadata entries back to a valid version.
164-164: Unique metadata key constraint.
This unique index across(key, versionId)avoids duplicating the same metadata key within a single version.
270-270: Exact match condition for tag.
Usingeq(deploymentVersion.tag, cond.value)for matching version tags is consistent with an equality-based filter.
272-272: StartsWith condition.
Applyingilike(deploymentVersion.tag, \${cond.value}%`)` for partial matching aligns with typical "startsWith" semantics.
274-274: EndsWith condition.
Usingilikewith\%${cond.value}`` checks trailing substrings in a case-insensitive manner.
276-276: Contains condition.
Allowing%${cond.value}%for substring searches lets users match tags containing partial patterns.
277-277: Regex condition fallback.
Employing~in PostgreSQL handles advanced pattern matching whencond.valueis a valid regex.
280-296: Generic buildCondition method.
Refactoring the function to acceptDeploymentVersionConditionunifies the various sub-condition builders under the updated version-based logic.
300-300: Optional condition parameter.
Acceptingcondition?: DeploymentVersionCondition | nullgracefully accommodates cases where no condition is provided.apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/_components/release/CreateRelease.tsx (22)
46-46: Refined import from validators.
ImportingdeploymentVersionConditionsets the stage for specifying version-based conditions rather than release-based ones.
47-47: Deployment version status usage.
EmployingDeploymentVersionStatusensures that the release creation logic stays aligned with supported version statuses.
54-57: New local schema for version dependency.
This replaces the older release dependency structure, tying each dependency to a particular deployment with aversionSelector.
62-62: Field rename totag.
Enforcing.min(1).max(255)ensures tags remain valid and within defined length constraints.
63-63: Validating status via DeploymentVersionStatus.
Requiring a valid status from the enum helps prevent invalid or deprecated states from creeping into the data.
64-68: Adopting versionDependencies within the release form.
Shifting to a version-centric approach and ensuring each dependency references a different deployment is sensible.
74-74: New optionaltagprop.
Offering a prop fortaglets external code prefill the version field for smoother user interaction.
83-83: Default tag fallback.
Usingprops.tag ?? ""prevents silently passingundefinedinto form values.
84-84: Default array initialization.
Setting theversionDependenciesdefault to an empty array avoids potential undefined references.
85-85: Initial status set to "Ready".
Starting each new version form in a “ready” state is reasonable unless users explicitly override it.
121-126: Sanitizing version selector.
Mapping throughversionDependenciesto nullify an uninitialized or emptyversionSelectorensures no extraneous conditions are stored.
129-129: Passing versionDependencies to the mutation.
Incorporating the mapped dependencies ensures the backend receives complete details about required version relationships.
130-130: Using trimmed tag as the version name.
Storingdata.tag.trim()innamecreates a cleaner, more standardized version label.
159-159: Field array updated to versionDependencies.
Wire-up touseFieldArraywithname: "versionDependencies"captures dynamic dependency entries.
162-162: TrackingversionDependencieserrors.
MaintainingformState.errors.versionDependenciesfor error reporting supports clearer user feedback if dependencies are invalid.
273-273: Refined field name for dependency deployment.
UtilizingversionDependencies.${index}.deploymentIdproperly indexes each dependent deployment reference.
306-306: Refined field name for dependency condition.
ApplyingversionDependencies.${index}.versionSelectorin the form structure ensures each dependency can have its own condition.
311-311: Fallback for condition.
UsingdefaultConditionfor a null or undefinedvaluekeeps the UI from displaying an undefined release condition dialog state.
343-343: Appending a blank dependency.
Starting off with empty fields fordeploymentIdandversionSelectorencourages clear user-driven input.
362-362: Status dropdown item for Ready.
Giving users an option to mark a version as immediately ready matches typical release workflows.
365-367: Status dropdown item for Building.
Allowing a “building” state conveys that the version is in progress before it’s fully deployable.
370-370: Status dropdown item for Failed.
Selecting “failed” indicates an unrecoverable state, ensuring the UI can depict and handle unsuccessful versions.packages/job-dispatch/src/environment-release-channel-update.ts (15)
1-1: No issues with the new import type.
30-58: Ensure logic for combining selectors is fully intended.The usage of
not: truewithin an AND condition can sometimes produce edge cases. If this matches your exact business requirements, confirm that you’re achieving the desired behavior. I can help verify all usage sites if needed.
60-66: Skipping job cancellation on null selector is valid.No concerns found with the early return approach.
83-83: Correct usage of deploymentVersionMatchesCondition.This ensures the database query filters by excluded version conditions properly.
97-100: Renamed function matches new naming convention.Good adoption of “Version” in
getLatestVersionFromSelector.
107-107: Consistent filter usage on versionSelector.Helps maintain the new version-based queries easily.
137-137: Renaming to handleVersionChannelUpdate is consistent with the new focus on versions.
145-148: Concurrent fetching of old/new selectors is optimal.No issues; Promise.all is a clean approach.
150-153: Clear usage of createSelectorForExcludedVersions.The code cleanly passes both
oldVersionSelectorandnewVersionSelector.
155-159: Initiating cancellation in parallel.Creating a cancellation promise is a good pattern for parallel execution later.
161-165: Parallel retrieval of latest versions.Using Promise.all to fetch both new and old versions simultaneously is optimal.
168-169: Guard to skip redundant triggers when new version is null or unchanged.Checks align with the refactor’s logic.
173-176: Triggering jobs for the newly identified version is straightforward.No issues with the updated function call.
181-184: Updated function name and channel argument usage.The shift to “VersionChannelUpdate” matches the overall refactor.
205-219: FlatMap usage for concurrency is concise and effective.Returning
Promise.all(environmentVersionChannelUpdatePromises)ensures all updates complete successfully.
...ployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx
Outdated
Show resolved
Hide resolved
...ployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx
Outdated
Show resolved
Hide resolved
| type DeploymentVersion = { | ||
| id: string; | ||
| version: string; | ||
| tag: string; | ||
| name: string; | ||
| createdAt: Date; | ||
| status: ReleaseStatusType; | ||
| status: DeploymentVersionStatusType; | ||
| deploymentId: string; | ||
| }; |
There was a problem hiding this comment.
Naming conflict with local type "DeploymentVersion."
A local type is being redeclared with the same name as the imported interface (line 25). This can lead to confusion or overshadowing.
Below is a suggested diff to rename the local type:
-type DeploymentVersion = {
+type LocalDeploymentVersionProps = {
id: string;
tag: string;
name: string;
createdAt: Date;
status: DeploymentVersionStatusType;
deploymentId: 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.
| type DeploymentVersion = { | |
| id: string; | |
| version: string; | |
| tag: string; | |
| name: string; | |
| createdAt: Date; | |
| status: ReleaseStatusType; | |
| status: DeploymentVersionStatusType; | |
| deploymentId: string; | |
| }; | |
| type LocalDeploymentVersionProps = { | |
| id: string; | |
| tag: string; | |
| name: string; | |
| createdAt: Date; | |
| status: DeploymentVersionStatusType; | |
| deploymentId: string; | |
| }; |
🧰 Tools
🪛 Biome (1.9.4)
[error] 27-27: Shouldn't redeclare 'DeploymentVersion'. Consider to delete it or rename it.
'DeploymentVersion' is defined here:
(lint/suspicious/noRedeclare)
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx (1)
25-34:⚠️ Potential issueFix the redeclared type identifier.
The
DepVersiontype at line 27 is being redeclared after already being imported as an alias at line 25. This is causing a static analysis error.Apply this diff to fix the type redeclaration:
-import { DeploymentVersion as DepVersion } from "./TableCells"; +import { DeploymentVersion } from "./TableCells"; -type DepVersion = { +type LocalDepVersion = { id: string; tag: string; name: string; createdAt: Date; status: DeploymentVersionStatusType; deploymentId: string; };Then update all references to
DepVersionin the file to useLocalDepVersioninstead.🧰 Tools
🪛 Biome (1.9.4)
[error] 27-27: Shouldn't redeclare 'DepVersion'. Consider to delete it or rename it.
'DepVersion' is defined here:
(lint/suspicious/noRedeclare)
🧹 Nitpick comments (3)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx (3)
169-170: Update UI text to maintain terminology consistency.The UI text still refers to "Release" instead of "Deployment Version" or similar terminology.
Apply this diff:
- Release is building + Version is building
175-175: Update UI text to maintain terminology consistency.The UI text still refers to "Release" instead of "Deployment Version" or similar terminology.
Apply this diff:
- <div className="text-center text-xs text-red-500">Release failed</div> + <div className="text-center text-xs text-red-500">Version failed</div>
192-192: Update UI text to maintain terminology consistency.The UI text still refers to "release channel" instead of "version channel" or similar terminology.
Apply this diff:
- release channel + version channel
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/DeploymentPageContent.tsx(10 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx(9 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/DeploymentPageContent.tsx
🧰 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/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsxapps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx
🪛 Biome (1.9.4)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/ReleaseEnvironmentCell.tsx
[error] 27-27: Shouldn't redeclare 'DepVersion'. Consider to delete it or rename it.
'DepVersion' is defined here:
(lint/suspicious/noRedeclare)
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Typecheck
- GitHub Check: build (linux/amd64)
- GitHub Check: Lint
🔇 Additional comments (1)
apps/webservice/src/app/[workspaceSlug]/(app)/(deploy)/(raw)/systems/[systemSlug]/(raw)/deployments/[deploymentSlug]/(sidebar)/_components/release-cell/VersionDistributionPopover.tsx (1)
8-35: Excellent refactoring of terminology!The component has been fully updated to use "version" terminology instead of "release" throughout the file. All variables, component names, and display text have been consistently renamed.
| export const LazyReleaseEnvironmentCell: React.FC< | ||
| ReleaseEnvironmentCellProps | ||
| DeploymentVersionEnvironmentCellProps | ||
| > = (props) => { | ||
| const { ref, inView } = useInView(); | ||
|
|
||
| return ( | ||
| <div className="flex w-full items-center justify-center" ref={ref}> | ||
| {!inView && <p className="text-xs text-muted-foreground">Loading...</p>} | ||
| {inView && <ReleaseEnvironmentCell {...props} />} | ||
| {inView && <DeploymentVersionEnvironmentCell {...props} />} | ||
| </div> | ||
| ); | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update the exported component name for consistency.
The exported component is still named LazyReleaseEnvironmentCell despite the renaming convention being applied throughout the file.
Apply this diff to maintain naming consistency:
-export const LazyReleaseEnvironmentCell: React.FC<
+export const LazyDeploymentVersionEnvironmentCell: React.FC<
DeploymentVersionEnvironmentCellProps
> = (props) => {
const { ref, inView } = useInView();
return (
<div className="flex w-full items-center justify-center" ref={ref}>
{!inView && <p className="text-xs text-muted-foreground">Loading...</p>}
{inView && <DeploymentVersionEnvironmentCell {...props} />}
</div>
);
};📝 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.
| export const LazyReleaseEnvironmentCell: React.FC< | |
| ReleaseEnvironmentCellProps | |
| DeploymentVersionEnvironmentCellProps | |
| > = (props) => { | |
| const { ref, inView } = useInView(); | |
| return ( | |
| <div className="flex w-full items-center justify-center" ref={ref}> | |
| {!inView && <p className="text-xs text-muted-foreground">Loading...</p>} | |
| {inView && <ReleaseEnvironmentCell {...props} />} | |
| {inView && <DeploymentVersionEnvironmentCell {...props} />} | |
| </div> | |
| ); | |
| }; | |
| export const LazyDeploymentVersionEnvironmentCell: React.FC< | |
| DeploymentVersionEnvironmentCellProps | |
| > = (props) => { | |
| const { ref, inView } = useInView(); | |
| return ( | |
| <div className="flex w-full items-center justify-center" ref={ref}> | |
| {!inView && <p className="text-xs text-muted-foreground">Loading...</p>} | |
| {inView && <DeploymentVersionEnvironmentCell {...props} />} | |
| </div> | |
| ); | |
| }; |
Summary by CodeRabbit
New Features
Refactor