Skip to content

@W-24217700 - work-item update/list fixes + stage branch/environment orphan guards - #523

Merged
ad-shreya merged 9 commits into
mainfrom
ashreya-workitem-response
Oct 5, 2026
Merged

ad-shreya merged 9 commits into
mainfrom
ashreya-workitem-response

Conversation

@ad-shreya

Copy link
Copy Markdown
Collaborator

@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?

  • Enforce work-item status transitions. A work item can now move to IN_PROGRESS only from NEW, and to READY_TO_PROMOTE only from IN_REVIEW. Invalid transitions are rejected with a clear, descriptive error before any update is sent.
  • Fix work-item update --description / --subject. These are plain WorkItem sObject fields — the connect work-item endpoint only accepts status — so they are now written via the sObject API, fixing the Unrecognized field "description" error. Status changes still go through the connect endpoint so platform-side status handling runs.
  • Show work item ID in work-item list. Added an ID column to the table so the record ID is visible alongside the name (the ID was already present in the query and --json output).
  • Fix misleading target branch for terminal-stage work items. The list previously fell back to the pipeline's first-stage branch whenever the next-stage lookup was empty, so a work item already on the last stage (e.g. a CLOSED item) wrongly displayed the first stage's branch. Now the first-stage fallback applies only when a work item hasn't entered the pipeline; a work item on a stage with no next stage correctly shows a blank target branch.
  • Prevent orphaning environments in stage environment add. Adding an environment to a stage that already has one previously created a new DevopsEnvironment and re-pointed the stage's lookup, orphaning the old record. The command now blocks by default with an actionable error, and a new --force flag removes the existing environment before adding the new one (aborting if that removal fails).
  • Snapshot update. Regenerated command-snapshot.json for the new stage environment add --force flag.
    #, @@

Functionality Before

<insert gif and/or summary>

Functionality After

<insert gif and/or summary>

ad-shreya and others added 6 commits September 22, 2026 12:58
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>
@ad-shreya
ad-shreya requested a review from a team as a code owner September 22, 2026 19:33
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>
@ad-shreya ad-shreya changed the title @W-24217700 - Ashreya workitem response @W-24217700 - work-item update/list fixes + stage branch/environment orphan guards Sep 23, 2026

@anuragbhoumick anuragbhoumick left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/utils/updateWorkItem.ts
Comment thread src/commands/devops/promote.ts Outdated
Comment thread src/utils/promoteStage.ts
): Promise<InFlightPromotion[]> {
validateSalesforceId(targetStageId, 'target stage');
const statusList = IN_FLIGHT_PROMOTION_STATUSES.join("', '");
const result = await connection.query<PipelineStagePromotionRecord>(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[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 anuragbhoumick left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well-structured PR bundling five targeted fixes with good test coverage across all changes. Two consistency/safety observations below.

Comment thread src/commands/devops/stage/environment/add.ts
Comment thread src/utils/updateWorkItem.ts
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>
@ad-shreya
ad-shreya merged commit 6d9f8b1 into main Oct 5, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants