Typed Parameters

compared with
Current by Yegor Yarko
on Aug 23, 2012 14:07.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (2)

View Page History
This specification is a parameter's "meta" information that is used to display parameter in [Run custom build|Triggering a Custom Build] dialog. It allows to make custom build run more user-friendly and usable by non-developers.
Consider a simple example. You have a build configuration in which you have a monstrous-looking build parameter that regulates if a build has to include license or not; can be either true or false; and by default is false. It may be clear for a build engineer, which build parameter regulates license generation and which value should it have, but it can be not obvious to a regular user. With build parameter's specification you can make your parameters more readable in "Run custom build" dialog. Currently you can present parameters in following forms:
|| Type || Description ||
| Text | The default. Represents a usual text string without any extra handling |
| Checkbox| True/false otpion represented with a checkbox. |
| Select | "Select one" or "select many" control to set the value to one of predefined settings|
| Password | {anchor:passwordField} This is designed to store passwords or other secure data in TeamCity settings. TeamCity makes the value of the password parameter never appear in TeamCity web UI: it affects settings screens and Run Custom Build dialog where the field is presented with password fields. Also, the value is replaced in the build's *Build Parameters* tab and build log. The value is stored scrambled in the configuration files under TeamCity Data Directory. Please note that build log value hiding is implemented with simple search-and-replace, so if you have a trivial password of "123", all occurrences of "123" will be replaced, potentially exposing the password.
Setting the parameter to type password does not guarantee that the raw value cannot be retrieved. Any project administrator can retrieve it and also any developer who can change the build script can in theory write malicious code to get the password. |

* simple text field with ability to validate its value using regular expression;
* check box;
Click *Allow* if you want to enable multiple selection. |

A password specification serves different purpose. It allows you to avoid storing passwords in settings. Instead, values of password parameters will be hidden from build log, and from *Build Parameters* tab of the build. Also it is impossible to see values of these parameters in custom build dialog. In configuration files such parameters are stored in scrambled form.
You may need a password typed parameter, for example, when deploying build artifacts to remote FTP repository. {tip}

h2. Manually configuring parameter's specification
Alternatively you can manually configure a specification using specially formatted string with syntax similar to the one used in service messages ({{typeName key='value'}}).