vcs triggered build missing from "builds" and "buildType" rest response

I have a project with a single build-type (that is vcs triggered) and I want to be able to query for the latest successful build of that project.

However, when I ask the REST API for the builds of that build-type I only get back an old one, not the latest. The only difference I can see between them is that the web link for the old one says "branch_my_project=<default>" and the vcs-triggered one says "branch_my_project=master".

I can accept there could be some misconfiguration in my vcs setup if it thinks that master is not the default branch, but that is independent of my question.

  • /httpAuth/app/rest/builds/ does not contain the build (of course, since this is my question)
  • /httpAuth/app/rest/buildTypes/id:my_type then follow the "builds.href" to /httpAuth/app/rest/buildTypes/id:my_type/builds/ does not contain the build
  • /httpAuth/app/rest/changes?project=my_project does show the change and the webLink says it is "personal=false" (which is what I would expect, since it was a vcsTriggered build)
  • /httpAuth/feed.html?buildTypeId=my_type&itemsType=builds does contain the build


I would expect that /app/rest/builds would show all builds, which it clearly does not. I would also expect /app/rest/buildTypes/id:my_type/builds to show the build.

This might be related to TW-5031 but I got the impression that it is asking for a report page, not for the REST functionality to function correctly.

Any insight will be appreciated!

6 comments
Comment actions Permalink

Please use /httpAuth/app/rest/builds/buildType:<myBT>/

For example: /httpAuth/app/rest/builds/buildType:One_One/

0
Comment actions Permalink

Using the url you provided only shows the build from 19 days ago, not the one that just happened 31 minutes ago.

Also, accessing a resource with a plural name of "builds" that only returns one result (i.e. not an array of items) is counterintuitive.

But thank you for the reply.

0
Comment actions Permalink

If you'd like to see all builds, please use the following URL: /httpAuth/app/rest/builds?locator=buildType:id:<myBT>

As mentioned below, the first URL returns the first suitable build, the second one - all build.
http://confluence.jetbrains.com/display/TCD8/REST+API#RESTAPI-BuildRequests

Also, by default, only builds from default branch are included into search results.

0
Comment actions Permalink

That link also does not contain the most recent builds; in my mental model adding filters to the /app/rest/builds link only narrows the results.

I was going to post a screenshot of the JSON results compared to the web UI, but someone rebooted TC and after the reboot the most recent successful builds disappeared from the "project.html" view but they are all present in the "buildTypeHistoryList" view. I think some graphics can help:

This is the project.html page, and prior to the reboot #92 was visible, but as was #100 (which one can see below)
Screen Shot 2014-04-28 at 11.50.36 AM.png

This is the buildTypeHistoryList view which contains all the expected bulids, and at the bottom contains the #92 from the overview.
Screen Shot 2014-04-28 at 11.45.05 AM.png

As I mentioned in my initial post, it is obviously bad news that refs/heads/master is highlighted different from "master" but they are all builds of the same build type, and thus I would expect two things: that they appear in /app/rest/builds (the unqualified link, all the builds on TC) and that they appear in /app/rest/buildTypes/id:my_type/builds/ but neither of those are true.

Just to make sure it wasn't overlooked, I'll repeat that they do appear in /httpAuth/feed.html?buildTypeId=my_id&itemType=builds&status=SUCCESSFUL which is what I am currently using to work around the REST API misunderstanding. If the /app/rest/builds would use the same SQL query that /feed.html does, I would think they would have a common view of the world.

Thank you for your continued time with this!

0
Comment actions Permalink

I assume that you use /refs/heads/* as a branch spec and you didn't put in a default branch name (changed in configuration, since build #92).

In your case, TC doesn't recognize master as a default branch and that's why it is showing its name on a light-blue background. The last build to default branch was #92 (tagged r/h/m).

What is your current branch spec and default branch is VCS settings?

Anyway, you can get builds from all branches by adding this locator: branch:default:any. The whole path will look like: /httpAuth/app/rest/builds/?locator=buildType:One_Git,branch:default:any


0
Comment actions Permalink

Adding branch:default:any appears to be the magic sauce.

The branch spec was +:refs/pull/*/merge and the default branch was (as you pointed out) refs/heads/master

I thought that I tried adding a branch qualifier to the API, but I obviously used the wrong syntax because I did not try the one you provided.

This has been valuable in understanding the status of the TC REST API, and I appreciate all the time and help you have given!

0

Please sign in to leave a comment.