ServiceDesk
ServiceDesk's API-driven architecture enables us to perform various actions on ServiceDesk using REST APIs. So, using Spinnaker's custom stage, tickets can be validated or updated and proceed with future actions in the pipeline.
ServiceDesk Custom Stage consists of the following four Stages:
GitOps style configuration
Execute the following steps to configure ServiceDesk custom stage for GitOps style:
Edit the orca-local.yaml file in the path “default/profiles/orca-local.yaml” from the GitHub repo.
Note: ServiceDesk domain and credentials are required to configure in the file.
2. In the webhook section find the ServiceDesk label and in the URL value replace it with the Domain. Replace in the four stages as listed above.
Non-GitOps style configuration
Execute the following steps to configure ServiceDesk custom stage for non-GitOps style.
Enter into the halyard pod as below mentioned.
kubectl exec -it <NAMESPACE>-spinnaker-halyard-0 -n <SPINNAKER_NAMESPACE> -- bash
Edit the orca-local.yaml file in the path “~/default/profiles/orca-local.yaml” from the GitHub repo.
In the webhook section find the ServiceDesk label and in the URL value replace it with the Domain. Replace in the four stages as listed above.
ServiceDesk: Create request-OpsMx
Create a request from the stage by providing the details with detailed information in the summary field.
To add “ServiceDesk: Create request-OpsMx” stage to your pipeline follow the steps below:
Go to your application and click “Pipeline builder” and click “Add Stage” and then select “ServiceDesk: Create request-OpsMx” stage from the drop-down menu as shown below.
2. Now the configuration screen appears to provide the required parameters.
Enter the following parameters on the above configuration screen:
Fail Fast HTTP Statuses: Comma-separated HTTP status codes (4xx or 5xx) that will cause this webhook stage to fail without retrying.
Description: Detailed description of the request.
Project ID: Project ID is a unique Id of your project in the organization.
Request Participants: Users who are going to be a part of this request.
Request Type ID: ID that the type of the request user is raising.
Summary: Subject of the request.
Wait for completion: Wait for the return response with the success or failure of the API call.
ServiceDesk: Comment on issue-OpsMx
An issue is to be commented on based on previous stage status with build and deployment as a comment to the issue is provided using the stage.
To add “ServiceDesk: Comment on issue-OpsMx” stage to your pipeline follow the steps below:
Go to your application and click “Pipeline builder” and click “Add Stage” and then select “ServiceDesk: Comment on issue-OpsMx” stage from the drop-down menu as shown below.
2. Now the configuration screen appears to provide the required parameters.
Enter the following parameters on the above configuration screen:
Fail Fast HTTP Statuses: Comma-separated HTTP status codes (4xx or 5xx) that will cause this webhook stage to fail without retrying.
Issue ID: ID of the request that has been raised.
Message: Comment on the issue of the request.
Wait for completion: Wait for the return response with the success or failure of the API call.
ServiceDesk: Wait for state-OpsMx
This is the stage that waits for a specific state on a ServiceDesk issue. Provide the “ServiceDesk Issue Id” and specify the “Retry state” until the desired state is occupied.
To add “ServiceDesk: Wait for state-OpsMx” stage to your pipeline follow the steps below:
Go to your application and click “Pipeline builder” and click “Add Stage” and then select “ServiceDesk: Wait for state-OpsMx” stage from the drop-down menu as shown below.
2. Now the configuration screen appears to provide the required parameters. Below is a use case that indicates the state will be polling until the state is changed to “In Verification”.
Enter the following parameters on the above configuration screen:
Fail Fast HTTP Statuses: Comma-separated HTTP status codes (4xx or 5xx) that will cause this webhook stage to fail without retrying.
ServiceDesk Canceled States: ServiceDesk issue states that cancel the pipeline. For example, Done, etc.
ServiceDesk Issue ID: ID of the request that has been raised. The default relies on ServiceDesk issue ID extraction.
ServiceDesk Retry States: ServiceDesk issue states that retry the stage. For example, To Do, In Progress, etc.
ServiceDesk Success States: ServiceDesk issue states that progress the pipeline. For example, In Verification, etc.
Delay before monitoring: Optional delay (in seconds) to wait before starting to poll the endpoint for monitoring status.
Retry HTTP Statuses: Normally, webhook stages only retry on 429 and 5xx status codes. You can specify additional status codes here that will cause the monitor to retry (for example, 404, 418).
Terminal status mapping: Comma-separated list of strings (that will be returned in the response body in the previously defined
statusJsonPath
field) that will be considered as TERMINAL status.Signal on cancellation: Triggers a specific webhook, if this stage is cancelled by the user or due to pipeline failure.
ServiceDesk: Transition issue-OpsMx
Change the state of an issue to a higher or lower state by providing the issue id and state. To add “ServiceDesk: Transition issue-OpsMx” stage to your pipeline follow the steps below:
Go to your application and click “Pipeline builder” and click “Add Stage” and then select “ServiceDesk: Transition issue-OpsMx” stage from the drop-down menu as shown below.
2. Now the configuration screen appears to provide the required parameters.
Enter the following parameters on the above configuration screen:
Fail Fast HTTP Statuses: Comma-separated HTTP status codes (4xx or 5xx) that will cause this webhook stage to fail without retrying.
Body: Message for transitioning the issue.
Issue ID: ID of the request that has been raised.
Target Stage ID: Target ID from the workflow of the project.
Wait for completion: Wait for the return response with the success or failure of the API call.
Last updated