Repository navigation
@W-24217700 - work-item update/list fixes + stage branch/environment orphan guards - #523
Conversation
sf devops stage environment add unconditionally created a new DevopsEnvironment and re-pointed DevopsPipelineStage.DevOpsEnvironmentId at it, orphaning the previously attached environment record. Add getStageEnvironment() to detect an existing environment and guard the add: block by default with a clear error, or with --force remove the existing environment (via deleteStageEnvironment) before adding the new one, aborting if that removal fails. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…Object Guard status changes so a work item can move to IN_PROGRESS only from NEW and to READY_TO_PROMOTE only from IN_REVIEW. Route subject/description updates through the WorkItem sObject (the connect work-item endpoint only accepts status), fixing the "Unrecognized field description" error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add an ID column to the work-item list table so the record ID is visible alongside the name. The ID was already in the query and JSON output. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The target branch fell back to the first stage whenever the next-stage lookup was empty, so a work item already on the last stage (e.g. a closed item) wrongly showed the first stage's branch. Only fall back to the first stage when the work item has not entered the pipeline; otherwise use its next stage's branch, leaving it blank when there is no next stage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sf devops stage branch add created a new SourceCodeRepositoryBranch and re-pointed DevopsPipelineStage.SourceCodeRepositoryBranchId at it, orphaning the previously associated branch record. Add getStageBranch() to detect an existing branch and guard the add: block by default with a clear error, or with --force associate the new branch and then remove the orphaned record (via deleteOrphanedBranch, which only deletes when no other stage references it). Cleanup is best-effort and warns on failure. Update the command snapshot for the new --force flag. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
anuragbhoumick
left a comment
There was a problem hiding this comment.
Review Summary: 2 warnings, 1 note across 31 files (1265+/51−). Well-structured PR — the status transition enforcement, orphan-prevention guards, and in-flight promotion check are solid additions with clean test coverage. Two ordering/error-handling concerns worth addressing.
| ): Promise<InFlightPromotion[]> { | ||
| validateSalesforceId(targetStageId, 'target stage'); | ||
| const statusList = IN_FLIGHT_PROMOTION_STATUSES.join("', '"); | ||
| const result = await connection.query<PipelineStagePromotionRecord>( |
There was a problem hiding this comment.
[NOTE] §00-common/Code Quality — SOQL query without LIMIT clause
Context: findInFlightPromotions queries DevopsPipelnStgProm filtered by stage + status with no LIMIT.
Issue: While in practice there should be 0–1 in-flight promotions per stage, an unbounded query in a governor-limited context could be expensive with unexpected data.
Suggestion: Add LIMIT 10 as a safety net, or LIMIT 1 and return a boolean since the caller only checks length > 0.
- updateWorkItem: run the status transition guard before the sObject write so a combined --subject/--status call cannot persist the subject change when the status transition is rejected (no partial update). - promote: surface a warning instead of silently swallowing the error when the in-flight promotion check fails, so operators know the duplicate-promotion guard was skipped. - promoteStage: add LIMIT 10 to the findInFlightPromotions SOQL query as a safety net. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
anuragbhoumick
left a comment
There was a problem hiding this comment.
Well-structured PR bundling five targeted fixes with good test coverage across all changes. Two consistency/safety observations below.
Environment --force replace now follows the add-then-cleanup pattern used by branch --force: the new environment is associated first and the old record is removed only on success, so a failed add no longer leaves the stage with no environment. Cleanup is best-effort (warns instead of failing) and only deletes an environment no other stage references. Work-item update now returns a partial-success result when the status Connect call fails after the subject/description sObject write has already committed, naming the fields that persisted instead of throwing a bare error that hides them. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@W-24217700@
What does this PR do?
This PR bundles several DevOps Center CLI fixes and enhancements around work items, the work-item list output, and adding environments to pipeline stages.
What issues does this PR fix or reference?
#, @@
Functionality Before
<insert gif and/or summary>
Functionality After
<insert gif and/or summary>