Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions .circleci/config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,9 +17,27 @@ jobs:
working_directory: ~/Tools
steps:
- checkout
- run:
name: Plan deployment
command: |
circleci run release plan "${CIRCLE_JOB}" \
--environment-name="default" \
--component-name="${CIRCLE_PROJECT_REPONAME}" \
--target-version="1.0.${CIRCLE_BUILD_NUM}-${CIRCLE_SHA1:0:7}"
- run:
name: "Deploy step"
command: echo "Deploying project..."
- run:
name: Update deployment status to running
command: circleci run release update "${CIRCLE_JOB}" --status=RUNNING
Comment on lines +30 to +32
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Bug: The deployment status update step lacks when: always, so it won't run if the preceding deployment step fails, leading to incomplete deployment tracking.
Severity: MEDIUM

Suggested Fix

Add the when: always condition to the "Update deployment status to running" step. This ensures that the deployment status is updated regardless of whether the preceding deployment step succeeds or fails, providing more robust and accurate deployment tracking.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: .circleci/config.yml#L30-L32

Potential issue: The CircleCI configuration places the "Update deployment status to
running" step after the deployment step. However, this status update step is missing the
`when: always` condition. While the current placeholder deployment command (`echo
"Deploying project..."`) will not fail, this configuration establishes a flawed pattern.
When a real, fallible deployment command replaces the placeholder, any failure in that
command will prevent the status update step from running. This will result in incomplete
deployment tracking.

Did we get this right? 👍 / 👎 to inform future reviews.

- run:
Comment on lines 27 to +33
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

1. Running set after deploy 🐞 Bug ≡ Correctness

In the deploy job, the Deploy Marker is updated to RUNNING only after the deploy command executes,
so the recorded deployment start/status is wrong and RUNNING is never emitted when the deploy step
fails. This breaks the accuracy of deployment visibility and duration metrics.
Agent Prompt
## Issue description
The deploy marker status is set to RUNNING after the deployment command, which makes the lifecycle tracking inaccurate and skips RUNNING on deployment failures.

## Issue Context
The current order is: plan -> deploy -> update RUNNING -> update SUCCESS/FAILED.

## Fix Focus Areas
- .circleci/config.yml[20-40]

## Suggested change
Move the "Update deployment status to running" step to immediately after "Plan deployment" and before the "Deploy step" so RUNNING reflects the actual start of deployment.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

name: Update deployment status to success
command: circleci run release update "${CIRCLE_JOB}" --status=SUCCESS
when: on_success
- run:
name: Update deployment status to failed
command: circleci run release update "${CIRCLE_JOB}" --status=FAILED
Comment on lines +23 to +39
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

2. Non-unique deployment id 🐞 Bug ≡ Correctness

All Deploy Marker plan/update commands use ${CIRCLE_JOB} as the deployment identifier, which
resolves to the constant job name "deploy" in this config. Multiple pipeline runs can overwrite each
other’s deployment records by updating the same id.
Agent Prompt
## Issue description
Using `${CIRCLE_JOB}` as the deploy marker identifier makes the id static (`deploy`), so different pipeline runs can update the same deployment record.

## Issue Context
The identifier passed as the first argument to both `circleci run release plan` and `circleci run release update` must be stable within a single run, but unique across runs.

## Fix Focus Areas
- .circleci/config.yml[20-40]

## Suggested change
Replace `${CIRCLE_JOB}` with a per-run unique id (while keeping it consistent across plan/update), for example:
- `${CIRCLE_WORKFLOW_ID}-${CIRCLE_JOB}`
- or `${CIRCLE_PIPELINE_ID}-${CIRCLE_JOB}`
Update all plan/update commands to use the same new identifier.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

when: on_fail
Comment on lines +30 to +40
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Action required

3. Marker updates fail deploy 🐞 Bug ☼ Reliability

The marker update steps run circleci run release update ... without guarding failures, so
transient tracking call failures can fail the deploy job even if the deployment succeeded. The
on_fail marker step can also fail and obscure the original deployment failure.
Agent Prompt
## Issue description
Deploy marker reporting commands can fail for reasons unrelated to deployment (network/auth/transient), but currently they can fail the entire job.

## Issue Context
Marker steps are auxiliary telemetry; deployment success/failure should be driven by the actual deploy command.

## Fix Focus Areas
- .circleci/config.yml[30-40]

## Suggested change
Wrap marker commands so they do not fail the job, e.g.:
- `circleci run release update ... --status=RUNNING || echo 'Deploy marker update failed'`
Optionally add a small retry loop for the marker calls, and ensure the FAILED marker step also cannot fail the job (so it doesn’t mask the real failure).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


workflows:
build-and-deploy:
Expand Down
Loading