The URL for downloading artifacts from #319 build of Custom_build_type will be like: While build_number is incrementing number of particular build (319): Build_type_id is the one given in configuration (Custom_build_type):
#TEAMCITY REST API DOWNLOAD#
To download artifact we would need, besides obvious TeamCity URL, so called build_type_id and build_number. Output of one build can be used as input to another without any middleman. Getting artifacts from other builds is one of the most useful TeamCity API features. As mentioned at the begging all examples will be based on Python library called requests together with shutil and xml. In the first part of this article we have focused on sending data to TeamCity, while the second part is about retrieving data with REST API. Such reported pair is visible in ‘Parameter/Reported statistics value’ tab and based on it new chart can be created: Every piece of data with a structure of key - float/int value can be put to TeamCity with following message: #teamcity Provided how? The answer is again – service messages. TeamCity provides some standard charts in Statistics tab like success rate or build duration:īut wat is more important it also gives possibility to create your own charts based on statistics provided. Will produce failed test in TeamCity with Error message: Will start and finish a test in TeamCity what will result in adding new test to Tests tab:Īdding fail message in the middle: #teamcity There are 2 basic messages for controlling test flow – starting and finishing and additional one for failing test. starting HTTP service and run tests on it - treat service startup as test with pass/fail criteria based on startup time). By ‘fake’ tests I understand part of functionality which we would like to be treated as test in TeamCity manner in order to have it’s statistics or history (i.e. Standard test libraries like junit or unittest have its own support and there is no need to handle anything unless you want to customize them by introducing your own pass/fail criteria or create ‘fake’ tests. TeamCity counts tests number and displays it in an overview label.
In case of builds with success status we can also customize build label using: #teamcity Where ‘foobar’ is an actual failure message: We have to tell TeamCity to do so by printing service message: #teamcity One may ask why, when TeamCity can do it by itself? That is true – but when we want to have more meaningful reason why it failed rather than simple: The simplest case when we would like to interfere with TeamCity behavior is to fail a build. Which needs to be printed into build log like e.g.: Service message is just a string in a format like: #teamcity
#TEAMCITY REST API HOW TO#
But usually this built-in TeamCity intelligence is not enough, and we have to tell it how to behave when specific condition is fulfilled. If your case hits this ideal situation then you’re lucky. In ideal situation TeamCity will do everything for us – fail/pass build, print intuitive message, count tests for us, even give possibility to create charts based on standard data.
0 kommentar(er)
