I am trying to figure out a way of returning all the last finished builds from teamcity. Essentially I am creating a status page for teamcity and want to show all the currently failing builds. So far I have tried various API calls. The following API call I thought for sure would give me all failures since the last successful builds, but it doesn't seem to work.
/guestAuth/app/rest/builds/?locator=status:failure,sinceBuild:(status:success)
Any help would be greatly appriciated. If I can get all the last finished builds, I can just sort to show only failures.
That REST call is correct. I am using TeamCity 7.1. Could it be that you simply haven't had any failures since the last successful build? Try inverting the conditions:
/guestAuth/app/rest/builds/?locator=status:success,sinceBuild:(status:failure)
This will return a list of successful builds since the last failure (the opposite). If you get results with this query, then your query should return no results. In otherwords, of these two queries:
/guestAuth/app/rest/builds/?locator=status:failure,sinceBuild:(status:success)
/guestAuth/app/rest/builds/?locator=status:success,sinceBuild:(status:failure)
At any given time, given that there are completed builds, one should ALWAYS return zero builds and the other should ALWAYS return one or more builds.
According to a comment on this JetBrains' ticket, since TeamCity 8.1 it is possible to use this API call to get the latest build status for all build configurations under a project:
http://teamcity.jetbrains.com/app/rest/buildTypes?locator=affectedProject:(id:TeamCityPluginsByJetBrains)&fields=buildType(id,name,builds($locator(running:false,canceled:false,count:1),build(number,status,statusText)))
Related
I'm trying to return completed tasks from the Asana API since a given date, but am getting back both complete and incomplete tasks.
Here's the request I'm making:
... #app.asana.com/api/1.0/tasks?workspace='+wkspce+'&completed_since='+computedDate+'&assignee=me&opt_fields=due_on,name,projects,tags,completed_at'
Any idea what I've done wrong
The completed_since parameter is a slight misnomer: it always includes incomplete tasks as well. It was originally intended as a way to get only tasks that are currently relevant - basically, a way to skip all the tasks that were completed ages ago (as a replacement for the old "archive" feature), so that for large projects you don't have to always fetch the entire thing.
I am using TeamCity 7.1. I want to get a list including the last build of each build configuration (build type) that is currently not running. I found this question: TeamCity - How do you get a list of the last finished build of each project through rest api? but the REST URI in the answer did not work for me.
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:failure)
seems to work and gives me all builds that succeeded after failing before.
But the opposite
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:success)
does not return any builds.
I know that I can get all build types, iterate though them and get the most recent finished build using
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false?count=1&start=0
("count=1&start=0" may not be necessary)
but I am not really sure that what I get is really the latest build. Also this requires many REST calls for all build types. A neat solution would use only one REST call.
Any ideas?
As per the TeamCity REST API documentation from JetBrains, the builds can be located either of the following ways:
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false,status:success
OR
<teamcity-server>/httpAuth/app/rest/builds/running:false,status:success
This is must to have the buildType is being suffixed by a <buildTypeLocator> as per the current REST API if you are trying to query something under the buildType and <buildTypeLocator> can be id:<btXXX_internal_buildConfiguration_id> or name:<Build_Configuration_name> (Quote from documentation). So it is must that you need to specify build id or build name.
But, the ideal way as you expected will be something like:
<teamcity-server>/httpAuth/app/rest/buildTypes/builds/running:false,status:success
Probably, you can raise this up in TeamCity Support I suppose.
Let's say I trigger build by sending GET request to /job/awesomesauce/build. Is it possible to retrieve id of triggered build?
I'm aware I can try to access /job/awesomesauce/lastBuild/api/json, but that would give me erroneous information in case there are multiple builds running at once. Additionally, there seem to be slight delay (few seconds) before it gives me information about currently running build.
I had to do this sort of thing, and here is a workaround I used: I had a dummy parameter that I passed to the build (in my case it was BUILD_ID of another build; in your case it may be a timestamp), I then queried and parsed both the build queue api ([server]/queue/api/...) and the regular api (in case the build has finished) for the build containing the appropriate parameter value.
In the http response header "location", you can get the queue item id. Then you can poll /queue/item//api/json to get its executable number, which is the build id.
I have Jenkins project that perform some sort of sanity check on couple of independent documents. Check result is written in JUnit XML format.
When one document test fails, entire build fails. Jenkins can be simply configured to send email to commiter in this situation. But I want to notify commiters only when new test failed or any failed test was fixed with the commit. They are not interested in failed tests for documents they have not edited. Email should contain only information of changes in tests, not full test report. Is it possible to send this kind of notification with any currently available Jenkins plugins? What could be the simplest way to achieve this?
I had the same question today. I wanted to configure Jenkins sending notifications only when new tests fail.
What I did was to install email-ext plugin.
You can find there a special trigger that is called Regression (An email will be sent any time there is a regression. A build is considered to regress whenever it hasmore failures than the previous build.)
Regarding fixed tests, there is Improvement trigger (An email will be sent any time there is an improvement. A build is considered to have improved wheneverit has fewer failures than the previous build.)
I guess that this is what you are looking for.
Hope it helps
There's the email-ext plugin. I don't think it does exactly what you want (e.g. sending only emails to committers who have changed a file that is responsible for a failure). You might be able to work around that/extend the plugin though.
Also have a look at the new Emailer, which talks about new email functionality in core hudson that is based on aforementioned plugin.
I was wondering if there was a way to do this in Hudson (or with any of the various plugins). My IDEAL scenario:
I want to trigger a build based on a job through a REST-like API, and on that build, I want it to return me a job ID. After-wards, I would like to poll this ID to see its status. When it is done, I would like to see the status, and the build number.
Now, since I can't seem to get that working, here is my current solution that I have yet to implement:
When you do a REST call to do a build, its not very REST-ful. It simply returns HTML, and I would have to do a kind of parsing to get the job ID. Alternatively, I can do a REST call for all the history listing all the jobs, and the latest one would be the one I just built. Once I have that, I can poll the console output for the output of the build.
Anyone know a way I can implement my "ideal" solution?
Yes, you can use the Hudson Remote API for this (as #Dan mentioned). Specifically, you need to configure your job to accept Remote Triggers (Job Configuration -> Build Triggers -> Trigger builds remotely) and then you can fire off a build with a simple HTTP GET to the right url.
(You may need to jump through a couple additional hoops if your Hudson requires authentication.)
I'm able to start a Hudson job with wget:
wget --auth-no-challenge --http-user=test --http-password=test "http://localhost:8080/job/My job/build?TOKEN=test"
This returns a bunch of HTML with a build number #20 that you could parse. The build number can then be used to query whether the job is done / successful.
You can examine the Hudson Remote API right from your browser for most of the Hudson web pages that you normally access by appending /api (or /api/xml to see the actual XML output), e.g. http://your-hudson/job/My job/api/.
Update: I see from your question that you probably know much of what I wrote. It is worth exploring the built-in Hudson API documentation a bit. I just discovered this tidbit that might help.
You can get the build number of the latest build (as plain text) from the URL: http://your-hudson/job/My job/lastBuild/buildNumber
Once you have the build number, I think the polling and job status is straightforward once you understand the API.
And what if you don't want the latest build number, but you want the build number of the build that was triggered by hitting the build URL ?
As far as I can tell, hitting that URL returns a 302 that redirects you to the job's mainpage, with no indication whatsoever of what the build number is of the one that you triggered.