Troubleshooting triggering a build for a specific branch.
Completed
I'm trying to trigger a build for a specific PR branch via the REST API, using the method described here:
https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-TriggeringaBuild
Thing is, not only is my build not starting, all I get in response to my call is the JSON with the build queue and nothing to indicate why my specific build couldn't be triggered. I'm pretty sure I have the correct build type ID, the branch and VCS checkout rules set in the project in question.
Is there a way to get more detailed information on what is happening and why my build isn't getting triggered from API call responses? As in invalid or missing values, wrong endpoints etc?
Please sign in to leave a comment.
TeamCity REST API response, in general, provides a hint on error; however, given that you can see the contents of build queue as a response, I would make a guess that there is a typo around HTTP method used - issuing GET instead of POST would pull the queue contents instead of triggering a new build, with no exceptions raised (please see more about how we handle different methods at https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-SupportedHTTPMethods). If this is not the case, could you please share an example of request you are making with the following details:
1) request method;
2) request headers/data;
3) an endpoint which is being called.
If you`d like to attach them as file, you could do so in a private manner via "Submit a request" form.
Method:
POST
Headers:
'Content-Type': 'application/xml'
'Accept': 'application/json'
Data:
Endpoint:
From what I can see in docs, this is how it's supposed to be done, am I missing something?
No, the request looks correct. Normally, you would expect a "build" typed node to be returned; could you provide a response for above request? Chances are the build is triggered but never started; https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-BuildRequests has an example on getting the build details, so if the response contains a build ID, you can try to execute the below request:
[GET] http://<endpoint>:<port>/httpAuth/app/rest/builds/id:<buildID>
to see what is the current status of the build in question (i.e. was it cancelled out, stuck in queue, etc.)
<Response [200]>
{"count":6,"href":"/httpAuth/app/rest/buildQueue/","build":[A LIST OF BUILDS IN THE QUEUE, BUT WITHOUT THE ONE I'VE BEEN TRYING TO TRIGGER]}
Speaking of wrong methods, I also tried using that old direct method described in docs as well:
https://www.jetbrains.com/help/teamcity/accessing-server-by-http.html?_ga=2.182261743.997377080.1586858600-1565851678.1582225073#AccessingServerbyHTTP-TriggeringaBuildFromScript
And it complained about me using a method other than POST even though that's exactly what I was using.
I have just tried to reproduce the setup; version in use is 2019.2.2. I have issued the following request (the same set of headers as you have listed above, basic auth):
[POST]http://localhost/httpAuth/app/rest/buildQueue
<build branchName="refs/heads/develop">
<buildType id="NugetPublisher_PublishNugetPackages"/>
</build>
and received the following response:
{"id":536,"buildTypeId":"NugetPublisher_PublishNugetPackages","state":"queued","branchName":"refs/heads/develop","href":"/httpAuth/app/rest/buildQueue/id:536",..
It has been followed by GET:
[GET]http://localhost/httpAuth/app/rest/buildQueue
b'{"count":1,"href":"/httpAuth/app/rest/buildQueue","build":[{"id":536,"buildTypeId":"NugetPublisher_PublishNugetPackages"...
What TeamCity version are you using? May I ask you to turn on REST debug logging as per this article (https://www.jetbrains.com/help/teamcity/teamcity-server-logs.html#TeamCityServerLogs-ChangingLoggingConfiguration) - you would need debug-rest, then execute the request again and send over extract from teamcity-rest.log located at <TeamCityServerDir>/logs folder?
In regards to the older method, please let me check internally on whether it`s still applicable.
Found the problem, there were some issues with routing and requests were going to port 80 instead of 8111. Fixed ports and now everything works. Thanks!
Glad it works now, thank you very much for coming back on this thread!