deployments.setPullServices
Associate a monorepo pull request with specific services.
Facts
| Method | POST https://yourinstance.getdx.net/api/deployments.setPullServices |
Arguments
| Name | Type | Description |
|---|---|---|
token |
Token |
Auth token passed as an HTTP header. |
github_pull_id |
Integer |
The GitHub pull request ID. Example: 1680723287 |
services |
Array<Object> |
An array of services that have been changed as part of this merge. The name field is optional. When empty and replace: true is set, all existing service assignments are removed and the pull request reverts to its default state, where it can be attributed to all services. |
replace |
Boolean |
When true, the submitted services list replaces all existing service assignments for this pull request. Any previously assigned services not present in the new list will be removed. Defaults to false, which adds the submitted services without removing any existing assignments. |
If pull_request_id cannot be provided, you can pass the repository and pull request number instead:
| Name | Type | Description |
|---|---|---|
repository |
Text |
The GitHub repository name, including the organization prefix. Example: orgname/payments |
pull_number |
Integer |
The GitHub pull request number. Example: ["234", "15352"] |
Usage info
Use this API method along with deployments.create for monorepos for situations where, since DX associates deployments to pull requests that have been merged since the previous deployment, past pull requests are attributed to deployments for the wrong service.
The setPullServices endpoint pre-associates pull requests with services, ensuring that they are attributed correctly when deployment data is later captured. For example, suppose the following events occur:
10 am - merge PR#1 (changes service_a)
11 am - merge PR#2 (changes service_b)
12 pm - merge PR#3 (changes service_a)
12:01 - deploy service_a
If setPullServices is used after each merge, then PR#1 and P#3 will associate to the deployment but PR#2 will not be considered deployed. If setPullServices is not used, then all pull requests will be considered deployed.
Example request
This is a typical request:
curl -X POST\
https://yourinstance.getdx.net/api/deployments.setPullServices\
-H "Content-Type: application/json" \
-H "Authorization: Bearer xxxx-xxxxxxxxx-xxxx" \
-d '{
"github_pull_id": 1497468863,
"services" : [
{
"name": "Payments",
"identifier": "payments-service"
},
{
"identifier": "auth-service"
}
],
}'
GitHub Action
Below is an example of a Github Actions workflow that gets the name of the services from the file changed in a pull request.
name: Scan Changed Files in PR
on:
pull_request:
types:
- closed
branches:
- 'main'
jobs:
scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
fetch-depth: 50 # pick an appropriate number
- name: Get list of changed files
id: getfile
run: |
files=$(git diff --name-only $ $ --)
echo "Changed files: $files"
echo "Changed files: $files" >> changed_files.txt
- name: Identify affected services
id: services
run: |
services=""
while read -r file; do
service=$(echo $file | awk -F'/' '{print $1}')
services="$services $service"
done < changed_files.txt
unique_services=$(echo $services | xargs -n1 | sort -u | xargs)
echo "Affected services: $unique_services"
echo "::set-output name=affected_services::$unique_services"
- name: Post affected services
run: |
services_json=$(echo "$" | jq -R 'split(" ") | map({identifier: .})')
json_payload=$(jq -n \
--arg github_pull_id $ \
--argjson services "$services_json" \
'{
github_pull_id: $github_pull_id,
services: $services
}')
curl -X POST \
http://yourinstance.getdx.net/api/deployments.setPullServices \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_BEARER_TOKEN_HERE" \
-d "$json_payload"
if [ "$RESPONSE_CODE" -ne 200 ]; then
ERROR_MESSAGE=$(jq -r '.message' response.txt)
ERROR_TYPE=$(jq -r '.error' response.txt)
echo "Error response from API: HTTP status code $RESPONSE"
echo "Error type: $ERROR_TYPE"
echo "Error message: $ERROR_MESSAGE"
exit 1 # Fail the step explicitly if an error is detected
fi
Errors
This table lists the expected errors that this method could return. However, other errors can be returned in the case where the service is down or other unexpected factors affect processing. Callers should always check the value of the ok param in the response.