Skip to main content

Troubleshooting

This section describes possible solutions to the issues that you might experience when using the CI/CD Manager API.

HTTP error codes​

The CI/CD Manager API uses the following error codes:

Error codeDescription
400 Bad RequestThe request is incorrect. A parameter, header, or body value failed validation, or the requested operation isn't allowed for the current state of the resource. Make sure the request body follows the schema.
401 UnauthorizedThe request is missing a valid access token, or the token expired. Check if your access token isn't expired.
403 ForbiddenYou aren't authorized to view or modify the requested resource. The feature is disabled for your tenant or you don't have sufficient permissions such as scope, Access Management permission, or Guidewire Hub group to perform this operation. Make sure you are in the right access group.
404 Not foundThe requested resource doesn't exist.
409 ConflictThe resource was modified concurrently by another process and the change couldn't be applied.
412 Precondition FailedThe request didn't meet one or more preconditions.
500 Internal Server ErrorAn unexpected error occurred while processing the request.
503 Service UnavailableCI/CD Manager Service is temporarily unavailable. Try again after a few minutes. You can also use the health check endpoint to learn more.
504 Gateway TimeoutThe request didn't complete within the configured time limit. Try again after a few minutes.

Response times out​

When a response times out, the CI/CD Manager Service might be temporarily unavailable. Try again after a few minutes.

Health check endpoint​

To verify the current state of the CI/CD Manager Service, use the health check endpoint:

GET {baseUrl}/management/health

Sample response:

{
  "status": "UP",
  "groups": ["liveness", "readiness"]
}

TeamCity issues​

Using the TeamCity UI to manually modify settings, creates a patch in the CI/CD repository. As a result, the CI/CD Manager API might introduce changes that are in conflict with the TeamCity settings.

Failed to load build settings from VCS error message​

If the latest configuration cannot be loaded, TeamCity runs the build with the latest valid configuration instead. As a result, the build completes with the Failed to load build settings from VCS error message. This does not necessarily mean that the build failed. It could pass with a different configuration instead.

To verify why the configuration could not be loaded, follow these steps:

  1. In TeamCity, open the project with the application you want to check.

  2. Go to Edit project > Versioned Settings.

  3. See the details under Current Status:

Example of a configuration status in TeamCity

To see the details of an invalid commit and the changes it introduced, go to the Change Log tab and click the commit hash:

Change log in TeamCity

Finally, verify the build logs to make sure that the build completed as expected. If it did, you can manually mark the build as successful.

Note:

To use the Mark as successful action, you need an Insurer Administrator role.

Incorrect CI/CD configuration​

Some issues can result from an incorrect CI/CD configuration. There are two endpoints which you can use to verify the existing configurations in your project.

  • To get a list of all applications and their CI configuration types, use the List all applications endpoint:
GET {baseUrl}/api/v2/tenants/{tenant_ID}/starsystems/{project_ID}/cicd-configs-metadata
GET {baseUrl}/api/v2/tenants/{tenantId}/starsystems/{starSystemId}/cicd-configs/{applicationId}/insurer-config

Unable to use GT Framework Tests template​

If the GT Framework Tests template is restricted, adding GT_TEST to a build schedule or post-deployment test returns a 400 Bad Request error. This error also occurs when you create a post-deployment test without testTypes in the request body, because it defaults to GT_TEST. To resolve this issue, use GTAPI_TEST or GTUI_TEST instead and always specify testTypes for post-deployment tests.

Existing schedules and tests that already use GT_TEST continue to run and can still be edited. If you remove GT_TEST from an existing schedule or test, you can't add it back.