Skip to content

Commit 808a48e

Browse files
committed
fix up sections in deploy markers page
1 parent ebda697 commit 808a48e

File tree

2 files changed

+18
-12
lines changed

2 files changed

+18
-12
lines changed

docs/guides/modules/deploy/pages/configure-deploy-markers.adoc

Lines changed: 18 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -11,12 +11,17 @@ Deploy markers provide a lightweight way to log your deployments without requiri
1111

1212
For a full guide to CircleCI's deploys features and functionality, refer to the xref:deployment-overview.adoc[Deployment and deploy management] guide.
1313

14+
You can configure deploy markers as follows:
15+
16+
* To display updated statuses depending of the outcome of your deployments. Steps for this are provided in the <<deploy-markers-with-status-updates>> section.
17+
* Or, you can choose to configure deploy markers to log deployments without status updates. Steps for this are provided in the <<deploy-logs-without-status-updates>> section.
18+
1419
== Prerequisites
1520

1621
* A CircleCI account connected to your code. You can link:https://circleci.com/signup/[sign up for free].
1722
* A CircleCI project with a workflow configured to deploy your code.
1823

19-
== 1. Update the configuration
24+
== Deploy markers with status updates
2025

2126
To create a deployment marker, you will update your CircleCI configuration file.
2227

@@ -102,6 +107,7 @@ jobs:
102107
=== 1.3. Update the deploy status to success or failure
103108
You can use the `when` attribute to add `on_success` and `on_failure` steps at the end of your deployment job, to handle the final status update of the deploy.
104109

110+
.Config file example showing deploy status update to success or failure
105111
[,yml]
106112
----
107113
jobs:
@@ -129,21 +135,23 @@ jobs:
129135
when: on_fail
130136
----
131137

132-
This will update the status of the deploy to `SUCCESS` or `FAILED` depending on the outcome of your job.
133-
In this example, the `failure_reason.env` file can be created by a previous step in the job. This can be done, for example, in a step in which we are validating the status of the deployment.
134-
You can do that as shown below:
138+
In this example, the status of the deploy is updated to `SUCCESS` or `FAILED` depending on the outcome of your job.
139+
140+
The `failure_reason.env` file can be created by a previous step in the job. This can be done, for example, in a step in which we are validating the status of the deployment. One way to do this is as follows:
135141

142+
.Create a file to store the failure reason
136143
[,yml]
137144
----
138145
echo "FAILURE_REASON='Deployment was not found'" > failure_reason.env
139146
----
140147

141148
CAUTION: Trying to update the status of the deploy after updating it to a terminal status such as `SUCCESS`, `FAILED` or `CANCELED` is not supported and will result in an error.
142149

143-
=== 1.3 Update the deploy status to canceled
150+
=== 1.4 Update the deploy status to canceled
144151

145152
If you want to update your deployment to `canceled` when the deploy job is canceled, you can do so by adding the following job to your configuration.
146153

154+
.Job configuration for updating the deploy status to canceled
147155
[,yml]
148156
----
149157
jobs:
@@ -163,6 +171,7 @@ jobs:
163171

164172
Then you can add it to your workflow as shown below.
165173

174+
.Workflow configuration for updating the deploy status to canceled. The cancel-deploy job only runs when the deploy job is canceled
166175
[,yml]
167176
----
168177
workflows:
@@ -175,9 +184,9 @@ workflows:
175184
- canceled
176185
----
177186

178-
This will make it sot that the job will be run only when the `deploy` job is canceled, thus updating the deployment to the `canceled` status.
187+
In this example, the `cancel-deploy` job will be run only when the `deploy` job is canceled, thus updating the deployment to the `canceled` status.
179188

180-
=== 2.4. Full config example
189+
=== 1.5. Full config example
181190

182191
For reference, here is a full example of a CircleCI config that makes use of the deployment tracking feature.
183192

@@ -236,7 +245,7 @@ workflows:
236245
- canceled
237246
----
238247

239-
== 3. Deploy logs
248+
== Deploy logs without status updates
240249

241250
Sometimes you might not want your deployment marker to have any specific status, but still want it to be logged in the deploys UI.
242251
In those cases you can use the `release log` command in place of `release plan` as shown in the example below.
@@ -312,5 +321,4 @@ By following the steps in this guide, you have added a deploy marker to your Cir
312321
You can now track the status of your deployments across your configured environments in the CircleCI deploys UI and in the project home page.
313322
You can now:
314323

315-
* xref:set-up-the-release-agent.adoc[Set up a release agent on your Kubernetes cluster].
316-
* xref:configure-deploy-markers.adoc[Learn about deploy markers]
324+
* xref:set-up-rollbacks.adoc[Set up rollbacks].

docs/guides/modules/deploy/pages/set-up-rollbacks.adoc

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -536,7 +536,5 @@ This will open the workflow re-run modal with the following options:
536536

537537
The workflow that originally deployed the selected version will be re-run, effectively performing a rollback to that version.
538538

539-
=== Important considerations
540-
541539

542540

0 commit comments

Comments
 (0)