We are starting to use Bamboo to monitor our builds, and we have started to use the "branches" facility from the build plans. These work great, except for one thing, on the wallboard, only the "main" build status is shown, not the status of the branches. Given that our branches are also release branches, we would like to see the status of the main branch and all of the "release" branches, but not the "hot fix", "feature", or "bug fix" branches.
Is this possible?
Try using a label:
https://confluence.atlassian.com/bamboo/displaying-the-wallboard-289276971.html
Also there is this:
https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html#Usingplanbranches-wallboard
But it looks like the wallboard is a bit of an unloved feature - they have some feature requests still open for it with a lot of watchers/votes that haven't been touched in three years or more.
You could also probably just implement your own wallboard and use the REST API to get statuses - the UI for wallboards is not very complex, and having your own javascript code accessing the REST API would give you complete control.
Related
I was tasked with creating a health check for our production site. It is a .NET MVC web application. There are a lot of dependencies and therefore points of failure e.g. a document repository, Java Web services, Site Minder policy server etc.
Management wants us to be the first to know if ever any point fails. Currently we are playing catch up if a problem arises, because it is the the client that informs us. I have written a suite of simple Selenium WebDriver based integration tests that test the sign in and a few light operations e.g. retrieving documents via the document api. I am happy with the result but need to be able to run them on a loop and notify IT when any fails.
We have a TFS build server but I'm not sure if it is the right tool for the job. I don't want to continuously build the tests, just run them. Also it looks like I can't define a build schedule more frequently than on a daily basis.
I would appreciate any ideas on how best achieve this. Thanks in advance
What you want to do is called a suite of "Smoke Tests". Smoke Tests are basically very short and sweet, independent tests that test various pieces of the app to make sure it's production ready, just as you say.
I am unfamiliar with TFS, but I'm sure the information I can provide you will be useful, and transferrable.
When you say "I don't want to build the tests, just run them." Any CI that you use, NEEDS to build them TO run them. Basically "building" will equate to "compiling". In order for your CI to actually run the tests, it needs to compile.
As far as running them, If the TFS build system has any use whatsoever, it will have a periodic build option. In Jenkins, I can specify a Cron time to run. For example:
0 0 * * *
means "run at 00:00 every day (midnight)"
or,
30 5 * 1-5 *
which means, "run at 5:30 every week day"
Since you are making Smoke Tests, it's important to remember to keep them short and sweet. Smoke tests should test one thing at a time. for example:
testLogin()
testLogout()
testAddSomething()
testRemoveSomething()
A web application health check is a very important feature. The use of smoke tests can be very useful in working out if your website is running or not and these can be automated to run at intervals to give you a notification that there is something wrong with your site, preferable before the customer notices.
However where smoke tests fail is that they only tell you that the website does not work, it does not tell you why. That is because you are making external calls as the client would, you cannot see the internals of the application. I.E is it the database that is down, is a network issue, disk space, a remote endpoint is not functioning correctly.
Now some of these things should be identifiable from other monitoring and you should definitely have an error log but sometimes you want to hear it from the horses mouth and the best thing that can tell you how you application is behaving is your application itself. That is why a number of applications have a baked in health check that can be called on demand.
Health Check as a Service
The health check services I have implemented in the past are all very similar and they do the following:
Expose an endpoint that can be called on demand, i.e /api/healthcheck. Normally this is private and is not accessible externally.
It returns a Json response containing:
the overall state
the host that returned the result (if behind a load balancer)
The application version
A set of sub system states (these will indicate which component is not performing)
The service should be resilient, any exception thrown whilst checking should still end with a health check result being returned.
Some sort of aggregate that can present a number of health check endpoints into one view
Here is one I made earlier
After doing this a number of times I have started a library to take out the main wire up of the health check and exposing it as a service. Feel free to use as an example or use the nuget packages.
https://github.com/bronumski/HealthNet
https://www.nuget.org/packages/HealthNet.WebApi
https://www.nuget.org/packages/HealthNet.Owin
https://www.nuget.org/packages/HealthNet.Nancy
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.
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)))
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.