Get all configuration settings via REST API in TC 10.0/2017.1
Up until REST API version 9.1, GET request to /app/rest/buildTypes/<id>/settings was returning all available settings of the configuration, regardless of whether they have a non-inherited value or not. Since 10.0, it only lists settings with non-inherited values, as well as _some_ settings that are always listed regardless of whether they have a custom value or not (not sure how the logic works here).
Not only we have a code that depends on available all settings being returned, it is also weird that the behavior is now different for parameters and settings (/app/rest/buildTypes/<id>/parameters will always list all available parameters).
Is it possible to make TeamCity list all settings, like it worked in 9.1?
I would not like to use an older API version for this specific query, because the newer version can differentiate between inherited and non-inherited values based on inherited="true" property, which is a useful addition.
Please sign in to leave a comment.
Hi Artem,
thanks for your request. Indeed, the behavior of the REST API was changed in this regard, so that only non-default values should be returned. This new behavior is intended and it's not currently possible to return them in the older way (other than using the 9.1 api).
If you could explain in particular what's your exact use case for the other values, we would be able to look into it deeper.
Hi Denis,
In our code, the application first gets all parameters and settings from server, and then, based on user-defined input, operates either on custom-only, inherited-only, or all values, based on "inherited" (previously "own") property. Now that settings also have a property to differentiate between custom and inherited values, I was hoping to introduce same mechanic for settings, just like it already works for parameters.
I strongly believe that application should decide what to use, not the server. If you've already gone to the trouble of adding "inherited" property for settings, there's no point in limiting developer's capabilities. Also, like I said before, current behavior introduces inconsistency, because settings and parameters behave differently, and because some settings are returned regardless of custom value.