fix: Convert completed to successful #287
Conversation
WalkthroughThis pull request introduces a comprehensive update to job status handling across the Ctrlplane application. The primary change involves replacing the Changes
Sequence DiagramsequenceDiagram
participant UI as User Interface
participant API as API Handler
participant DB as Database
participant Validator as Job Status Validator
UI->>Validator: Request job status check
Validator->>API: Validate job status
API->>DB: Query jobs with new status
DB-->>API: Return jobs
API-->>UI: Render job status as 'Successful'
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (5)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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: 2
🧹 Nitpick comments (4)
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowNode.tsx (1)
43-43: Consider enhancing the badge with status colors.The successful/total ratio display is correct. Consider enhancing the UX by color-coding the badge based on the success ratio (e.g., green when all jobs are successful).
- {successful?.length} / {environmentJobs?.length} + <span className={cn( + "text-muted-foreground", + successful?.length === environmentJobs?.length && "text-green-500" + )}> + {successful?.length} / {environmentJobs?.length} + </span>apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowPolicyNode.tsx (1)
Line range hint
54-54: Fix typo in success message.There's a typo in the word "sucessfully" (missing a 'c').
- completed sucessfully + completed successfullypackages/job-dispatch/src/queue/db.ts (1)
7-7: LGTM! Good transition to enum usage.The change improves type safety by using JobStatus enum instead of string literals. Consider extracting the excluded statuses array to a constant if it's used elsewhere in the codebase.
+const EXCLUDED_JOB_STATUSES = [ + JobStatus.Failure, + JobStatus.Cancelled, + JobStatus.Skipped, + JobStatus.Successful, + JobStatus.InvalidJobAgent, +] as const; async next(agentId: string): Promise<Job[]> { const jobs = await this.db .select() .from(job) .where( and( eq(job.jobAgentId, agentId), - notInArray(job.status, [ - JobStatus.Failure, - JobStatus.Cancelled, - JobStatus.Skipped, - JobStatus.Successful, - JobStatus.InvalidJobAgent, - ]), + notInArray(job.status, EXCLUDED_JOB_STATUSES), isNull(job.externalId), ), );Also applies to: 28-32
packages/validators/src/jobs/index.ts (1)
8-8: LGTM! Consider updating documentation.The status change is consistently applied across the enum, readable mapping, and exitedStatus array. Consider updating any API documentation or user guides that might reference the old "completed" status.
Run this script to find documentation files that might need updates:
#!/bin/bash # Search for documentation files containing "completed" status rg -i "completed" --type md --type mdx --type txtAlso applies to: 23-23, 39-39
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
apps/webservice/src/app/[workspaceSlug]/(app)/(resources)/resources/[resourceId]/ReleaseCell.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/(resources)/resources/[resourceId]/visualize/nodes/DeploymentNode.tsx(4 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/DailyJobsChart.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/JobTableStatusIcon.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobComparisonConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/RunbookJobComparisonConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/resource-drawer/DeploymentContent.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/TableCells.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowNode.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowPolicyNode.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/status-color.tsx(1 hunks)apps/webservice/src/app/api/github/webhook/workflow/handler.ts(1 hunks)apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts(2 hunks)apps/webservice/src/app/api/v1/openapi.ts(2 hunks)openapi.v1.json(2 hunks)packages/api/src/router/deployment.ts(1 hunks)packages/db/drizzle/0060_stale_warlock.sql(1 hunks)packages/db/drizzle/meta/_journal.json(1 hunks)packages/db/src/schema/job.ts(1 hunks)packages/job-dispatch/src/job-update.ts(1 hunks)packages/job-dispatch/src/policies/release-dependency.ts(1 hunks)packages/job-dispatch/src/policies/success-rate-criteria-passing.ts(1 hunks)packages/job-dispatch/src/queue/db.ts(2 hunks)packages/validators/src/jobs/conditions/status-condition.ts(1 hunks)packages/validators/src/jobs/index.ts(3 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/db/drizzle/0060_stale_warlock.sql
🧰 Additional context used
📓 Path-based instructions (22)
apps/webservice/src/app/[workspaceSlug]/(app)/(resources)/resources/[resourceId]/ReleaseCell.tsx (1)
Pattern **/*.{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)/_components/JobTableStatusIcon.tsx (1)
Pattern **/*.{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/api/src/router/deployment.ts (1)
Pattern **/*.{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/validators/src/jobs/conditions/status-condition.ts (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
packages/job-dispatch/src/policies/release-dependency.ts (1)
Pattern **/*.{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)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowNode.tsx (1)
Pattern **/*.{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/job-update.ts (1)
Pattern **/*.{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/db/src/schema/job.ts (1)
Pattern **/*.{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)/_components/resource-drawer/DeploymentContent.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/v1/openapi.ts (1)
Pattern **/*.{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)/systems/[systemSlug]/deployments/status-color.tsx (1)
Pattern **/*.{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)/(resources)/resources/[resourceId]/visualize/nodes/DeploymentNode.tsx (1)
Pattern **/*.{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)/_components/job-condition/JobComparisonConditionRender.tsx (1)
Pattern **/*.{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)/_components/DailyJobsChart.tsx (1)
Pattern **/*.{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)/systems/[systemSlug]/deployments/TableCells.tsx (1)
Pattern **/*.{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)/_components/job-condition/RunbookJobComparisonConditionRender.tsx (1)
Pattern **/*.{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/validators/src/jobs/index.ts (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)
Pattern **/*.{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/queue/db.ts (1)
Pattern **/*.{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)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowPolicyNode.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/api/github/webhook/workflow/handler.ts (1)
Pattern **/*.{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/success-rate-criteria-passing.ts (1)
Pattern **/*.{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.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Typecheck
- GitHub Check: Lint
- GitHub Check: build (linux/amd64)
🔇 Additional comments (26)
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowNode.tsx (1)
26-27: LGTM! Status filter updated correctly.The change from completed to successful status is implemented correctly with proper null safety.
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/[deploymentSlug]/releases/[versionId]/FlowPolicyNode.tsx (3)
47-48: LGTM! The status check is now more precise.The change from checking completed to successful status provides a more accurate count of passing jobs.
59-60: LGTM! Variable name accurately reflects the status check.The change from
areAllCompletedtoareAllSuccessfulmaintains semantic clarity while implementing the status change.
64-66: LGTM! UI text consistently reflects the status change.The message update from "completed" to "successful" maintains consistency with the new status terminology.
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/status-color.tsx (1)
5-5: LGTM! Color mapping maintained correctly.The status color mapping has been updated from "completed" to "successful" while maintaining the appropriate green[400] color for success state.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/JobTableStatusIcon.tsx (1)
17-20: LGTM! Status terminology update is consistent.The change from
JobStatus.CompletedtoJobStatus.Successfulmaintains the same visual feedback while improving status terminology precision.apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)
42-46: LGTM! Verify database queries still work as expected.The status update from "completed" to "successful" in the query filter is consistent with the terminology change.
Let's verify that no jobs are stuck in an old "completed" status:
✅ Verification successful
Database migration properly handles the status rename
The migration file
packages/db/drizzle/0060_stale_warlock.sqlensures all jobs with 'completed' status are renamed to 'successful'.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if any jobs still have the old "completed" status rg -i "status.*completed" --type sqlLength of output: 395
apps/webservice/src/app/[workspaceSlug]/(app)/(resources)/resources/[resourceId]/ReleaseCell.tsx (1)
Line range hint
40-46: LGTM! Status update is consistent with enum usage.The change from
JobStatus.CompletedtoJobStatus.Successfulis properly implemented using the JobStatus enum.apps/webservice/src/app/api/github/webhook/workflow/handler.ts (1)
12-17: LGTM! Consistent mapping of GitHub workflow statuses.The changes correctly map GitHub workflow statuses to our internal JobStatus enum:
- GitHub's "success" conclusion → JobStatus.Successful
- GitHub's "completed" status → JobStatus.Successful
Also applies to: 23-23
packages/job-dispatch/src/policies/success-rate-criteria-passing.ts (1)
41-41: LGTM! Consistent success criteria evaluation.The changes correctly update the success criteria evaluation to use JobStatus.Successful while maintaining the original logic for policy evaluation.
Also applies to: 44-46
packages/job-dispatch/src/job-update.ts (1)
113-114: Verify impact on job completion handlers.The change from JobStatus.Completed to JobStatus.Successful affects when onJobCompletion is triggered. Please verify that all downstream processes expecting job completion events are updated accordingly.
apps/webservice/src/app/[workspaceSlug]/(app)/(resources)/resources/[resourceId]/visualize/nodes/DeploymentNode.tsx (1)
42-43: LGTM! Consistent UI status representation.The changes correctly update the deployment node visualization to reflect JobStatus.Successful:
- Status check logic updated
- CSS classes updated consistently
Also applies to: 55-55, 84-84, 96-96
apps/webservice/src/app/api/v1/openapi.ts (2)
121-121: LGTM! Status enum value updated consistently.The change from "completed" to "successful" in the Job schema's status enum aligns with the PR objective.
141-142: Verify API consumers are prepared for the new timing fields.The addition of
startedAtandcompletedAtfields enhances job tracking capabilities. However, ensure that API consumers are notified of these additions.Consider documenting the behavior of these fields:
- When exactly is
startedAtset?- What triggers the update of
completedAt?- Are there any scenarios where one field might be set without the other?
packages/job-dispatch/src/policies/release-dependency.ts (1)
125-125: Verify deployment flows with the updated policy check.The change from
JobStatus.CompletedtoJobStatus.Successfulin the dependency policy check is logically correct but could affect existing deployment flows.Run this script to identify potentially affected deployments:
apps/webservice/src/app/[workspaceSlug]/(app)/systems/[systemSlug]/deployments/TableCells.tsx (1)
88-88: LGTM! Status checks updated consistently.Both
isCompleteandisRollingOutchecks have been updated to useJobStatus.Successful, maintaining consistency with the new status terminology.Also applies to: 96-96
apps/webservice/src/app/[workspaceSlug]/(app)/_components/DailyJobsChart.tsx (1)
35-35: LGTM! Chart display updated consistently.The status mappings in both
statusColorsandstatusLabelshave been updated to useJobStatus.Successful, maintaining visual consistency in the chart display.Also applies to: 45-45
packages/db/src/schema/job.ts (1)
54-54: Verify validators package update.Since this is a source of truth for job statuses, ensure that
@ctrlplane/validators/src/jobs/index.tshas been updated to reflect this change.✅ Verification successful
Validators package is already correctly configured
The validators package already uses "successful" as the job status value in both:
packages/validators/src/jobs/index.ts:JobStatus.Successful = "successful"packages/validators/src/jobs/conditions/status-condition.ts: includes "successful" in the status enum🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the validators package has been updated with the new status. # Test: Search for both old and new status values in the validators package. # Expect: Only "successful" should be found, not "completed" rg -i "completed.*status" packages/validators/src/jobs/ rg -i "successful.*status" packages/validators/src/jobs/Length of output: 116
Script:
#!/bin/bash # First, verify the validators package location and structure fd validators fd . packages/validators/src/jobs/ || true # Then, look for any job-related files rg -l "job.*status|status.*job" || true # Use ast-grep to find status-related code patterns ast-grep --pattern 'status = $_' || true ast-grep --pattern 'status: $_' || trueLength of output: 6754
Script:
#!/bin/bash # Check the content of the main jobs files in validators package cat packages/validators/src/jobs/index.ts cat packages/validators/src/jobs/conditions/status-condition.ts # Broader search for status-related definitions rg -A 5 -B 5 "status.*=|type.*Status|enum.*Status|interface.*Status" packages/validators/src/jobs/Length of output: 7751
apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/RunbookJobComparisonConditionRender.tsx (1)
304-304: LGTM!The status value has been correctly updated to use
JobStatus.Successfulin the dropdown menu item.apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobComparisonConditionRender.tsx (1)
303-303: LGTM!The status value has been correctly updated to use
JobStatus.Successfulin the dropdown menu item.packages/api/src/router/deployment.ts (2)
665-665: LGTM!The job status has been correctly updated to use
JobStatus.Successfulin the array of valid statuses for the query filter.
Line range hint
665-669: Verify all status checks in the codebase.Let's ensure all similar status checks have been updated consistently across the codebase.
✅ Verification successful
Status checks are properly handled across the codebase ✅
The codebase consistently handles job status transitions. While external integrations may use "completed", these are properly mapped to
JobStatus.Successfulinternally, as evidenced by the webhook handler and database migrations.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining references to JobStatus.Completed # Test: Search for "completed" in relation to job status # Expect: No instances of JobStatus.Completed or similar patterns # Search for completed status in TypeScript/JavaScript files rg -g '*.{ts,tsx,js,jsx}' -i 'status.*completed|completed.*status' # Search for completed in SQL migrations rg -g '*.sql' -i 'completed.*status|status.*completed'Length of output: 965
packages/db/drizzle/meta/_journal.json (1)
424-430: LGTM! Migration entry follows the established pattern.The new migration entry is properly formatted and maintains consistency with existing entries in terms of structure and properties.
openapi.v1.json (3)
2637-2637: Status enum update aligns with PR objective.The addition of "successful" status aligns with the PR's goal of converting from "completed" to "successful" status.
2658-2661: LGTM! New updatedAt field properly defined.The updatedAt field is:
- Properly typed as a date-time string
- Added to the required fields
- Consistent with other timestamp fields in the schema
Line range hint
2658-2667: Well-structured job lifecycle tracking.The combination of timestamp fields (createdAt, updatedAt, startedAt, completedAt) provides comprehensive tracking of job state transitions, which is valuable for monitoring and debugging.
| @@ -1,7 +1,7 @@ | |||
| import { z } from "zod"; | |||
|
|
|||
| export const jobStatus = z.enum([ | |||
| "completed", | |||
| "successful", | |||
There was a problem hiding this comment.
💡 Codebase verification
Update required in dependent files for status value change
The change from "completed" to "successful" requires updates in:
packages/node-sdk/src/schema.ts: Still includes "completed" in the status union typeapps/webservice/src/app/api/github/webhook/workflow/handler.ts: Maps external "completed" status to JobStatus.Successful
🔗 Analysis chain
LGTM! Verify usage of updated status value.
The change from "completed" to "successful" in the zod schema is consistent with the PR objective.
Let's verify that all usages of the old status value have been updated:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining instances of "completed" status
rg -i "completed" --type ts
Length of output: 5482
There was a problem hiding this comment.
the first one I will do in a separate commit, the second one is intentional
There was a problem hiding this comment.
@adityachoudhari26 Understood! Thanks for clarifying the webhook handler's intentional mapping.
✏️ Learnings added
Learnt from: adityachoudhari26
PR: ctrlplanedev/ctrlplane#287
File: packages/validators/src/jobs/conditions/status-condition.ts:4-4
Timestamp: 2025-01-21T19:52:22.687Z
Learning: In apps/webservice/src/app/api/github/webhook/workflow/handler.ts, the external "completed" status is intentionally mapped to JobStatus.Successful to handle GitHub workflow status conversions.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
If you found this review helpful, would you consider giving us a shout-out on X?
Thank you for using CodeRabbit!
| deployment.releaseJobTrigger?.job.status === "successful" && | ||
| "bg-green-500/30 text-green-400 text-muted-foreground", |
There was a problem hiding this comment.
Use JobStatus enum instead of hardcoded string.
To maintain consistency and prevent potential bugs, replace the hardcoded "successful" string with JobStatus.Successful.
Apply this diff:
- deployment.releaseJobTrigger?.job.status === "successful" &&
+ deployment.releaseJobTrigger?.job.status === JobStatus.Successful &&
"bg-green-500/30 text-green-400 text-muted-foreground",Committable suggestion skipped: line range outside the PR's diff.
Summary by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes
Chores