Return builds where there are artifacts published

Answered

I'm trying to select 50 builds within a configuration. I would like to filter out the builds that do not have published artifacts.

Here is an example of my query: http://teamcity:8111/app/rest/builds?count=50&locator=buildType:configA,running:false,canceled:any,branch:default:any,status:success,build(number,id,buildTypeId,startDate,branchName,changes(count,href,change),artifacts(count))

 

I've been trying to play with $locator(name:(value:(<regexp>),matchType:matches)) with no success.

 

Can anyone offer a suggestion?

4 comments
Comment actions Permalink

Hello Kevin,

I have just confirmed with the development team that, unfortunately, filter by artifacts availability is not supported for the builds endpoint. 
As a possible workaround, if you are going to need this request on a regular basis, may I suggest to tag the builds with published artifacts (either manually or via REST API, which could be called from the build directly):

curl -s  --header "Authorization: Bearer $TOKEN" \
    -H 'Content-Type: text/plain' \
    "https://yourhost/app/rest/builds/id:<buildID>/tags --data has_artifacts

You could then use the tag for filtering.
Could you please provide some details on your use case? Perchance I will be able to suggest something else.

0
Comment actions Permalink

Hi Fedor,

Thanks for the reply.

 

However I don't think your suggestion would work well. Even if we tag each build that has artifacts, we would have to clean up those tags somehow when the artifact cleanup process executes.

 

As for our use case, we have a application that queries TeamCity for artifacts to download. We would like to limit the builds returned back from TeamCity to only include builds that have artifacts.Currently, TeamCity currently returns builds that have artifacts and some that do not. We then have to filter further on the application side to isolate builds that only have artifacts. This also requires more calls (pagination) and then pick a hard stop in which we are guessing there would be no more builds.

0
Comment actions Permalink

Hello Kevin,

I agree that this might be inconvenient for your use case. One possible workaround I could think of is to modify your request like below:

/app/rest/builds?locator=buildType:<buildTypeID>,running:false,canceled:any,branch:default:any,status:success,count:10000,sinceDate:20200528T000000%2B0300&fields=build(number,id,buildTypeId,startDate,branchName,changes(count,href,change),artifacts(count))

SinceDate locator part is here to filter out builds which are likely to be cleaned up already (depending on the clean-up rules setup). Count:10000 is chosen to allow more items into the selection without pagination being required (the request may be hard to process depending on your setup, so please feel free to modify the Count property accordingly). 

I have created a corresponding feature request on our tracker: https://youtrack.jetbrains.com/issue/TW-66356 - please vote for it as you see fit. 
If you have any other questions, please also let me know. 

0
Comment actions Permalink

Thanks Fedor for creating that feature request.

 

I'll forward your suggestion to the app developer.

0

Please sign in to leave a comment.