REST API: Configuration Manager

On this page:

1 URI structure
2 Step-by-step guide for using the API
- 2.1 Create a new snapshot*
- 2.2 Get snapshot metadata
- 2.3 Download a snapshot ZIP
- 2.4 Delete a snapshot
- 2.5 Start a deployment operation
- 2.6 Upload a snapshot ZIP file
- 2.7 Check the deployment status
3 Issue migration
4 Conflicting custom fields
5 Status code 500 while creating a snapshot
- 5.1 Error body

For details and examples, take a look at the REST API reference:

Documentation for REST API 1.6 - available with Configuration Manager 6.14.0 or later.

URI structure

Configuration Manager's REST API provides means to manage snapshots via URI paths. URIs for Configuration Manager's REST API resource have the following structure:

http://host:port/context/rest/configuration-manager/api/api-version/resource-name

The current API version is 1.6.

For example, you would use the following path to access the snapshots' API on a locally run instance of Jira with a context path of /jira:

http://localhost:2990/jira/rest/configuration-manager/api/1.6/snapshots

Context Path

The example above specifies a context path of “/jira”. Keep in mind that the context path may be different or not present for your installation of Jira.

Step-by-step guide for using the API

Create a new snapshot*

POST /snapshots

This snapshot endpoint creates a new snapshot.

Request

Unix/macOS request

Windows request

Responses

Get snapshot metadata

GET /snapshots

This snapshot endpoint returns all snapshots' metadata attributes (i.e., no actual snapshot files, just the snapshot metadata).

Request

Responses

Download a snapshot ZIP

GET /snapshots/{id}

This snapshot endpoint returns a specified snapshot as a ZIP containing a snapshot file in a binary format.

Request

Responses

Delete a snapshot

DELETE /snapshots/{id}

This snapshot endpoint deletes a specified snapshot.

Request

Responses

Start a deployment operation

POST /deployments

Deployment is a two-step process:

Meta information is provided.
A snapshot file is uploaded.

A separate REST endpoint is used for tracking deployment progress.

The “Start a deployment operation” is the first step of the deployment process. The request parameters provide the meta information required.

Request

Unix/macOS request

Windows request

Responses

Upload a snapshot ZIP file

PUT /deployments/{id}/content

This endpoint uploads the snapshot content during deployment.

The snapshot content must be provided in a part named 'file' within a multipart/form-data body. After the content is successfully uploaded, the deployment process will start.

Uploading a snaphot zip file is a required step after starting the deployment operation.

Request

Responses

Check the deployment status

GET /deployments/{id}

Returns the status of the deployment operation with the given id.
This "id" is received as a response to the “Start a deployment operation” request.

Request

Responses

Status: “waiting”

You will receive the "waiting" status as a response in the following cases:

the snapshot zip file you want to deploy is still uploading;
you haven’t uploaded a snapshot zip file.

Uploading a snapshot zip file is a required step in the deployment operation and the "waiting" status will not change until you provide a file.

Issue migration

In certain situations deploying a configuration snapshot may require migration of issues (e.g., when a workflow status is deleted and there are issues with this status). Note that this is different than deploying a snapshot with issues. This is not supported by the REST API, as migration requires user input. The following response will be returned:

{
  "id" : 1,
  "status" : "failed",
  "message" : "Data migration is required - automated deployment cannot continue."
}

In this case, the deployment will have to be performed through the user interface.

More information on issue migration can be found here.

Conflicting custom fields

Due to the fact that Jira allows the existence of multiple custom fields with the same name and type on a single system, it is not always possible to directly match custom fields on the snapshot to fields on the target system. More information on duplicate custom fields can be found here. CMJ allows these conflicts to be resolved from the GUI, as described here.

When using the REST API for deployment and such a case is detected, the deployment stops, and an error message is shown.

You can perform the deployment through the GUI and select the proper matching.
If you want to perform the deployment anyway, the error severity type can be reduced to a warning showing the same message, which doesn't stop the deployment. This is controlled by the General Settings' "Stop deployment in case of possible data loss".
The duplicate fields on the source Jira can be temporarily renamed before creating the snapshot. The duplicate fields on the target instance can be temporarily renamed before deploying the snapshot in order to get properly matched.

Status code 500 while creating a snapshot

If there are Integrity Check errors present, CMJ will return status code 500 with the first error in the body. To find all errors, use Integrity Check through the UI or REST API.

Error body

{
  "messages": [
    "com.botronsoft.jira.rollout.integrity.IntegrityViolationException: Workflow <a href=\"/jira/secure/admin/workflows/ViewWorkflowSteps.jspa?workflowMode=live&workflowName=Sales+Workflow\" target=\"_blank\">'Sales Workflow'</a> refers to the missing custom field <b>customfield_10201</b>."
  ]
}