TeamCity
 
You are viewing the documentation for an earlier version of TeamCity.

Typed Parameters

Last modified: 20 April 2023

When adding a build parameter (system property, environment variable or configuration parameter), you can extend its definition with a specification that will regulate parameter's control presentation and validation. This specification is the parameter's "meta" information that is used to display the parameter in the Triggering a Custom Build dialog. It allows making a 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 a 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 it is to have, but it may not be obvious to a regular user.

Using the build parameter's specification you can make your parameters more readable in the Run Custom Build dialog.

Adding Parameter Specification



To add specification to a build parameter, click the Edit button in the Spec area when editing/adding a build parameter.

All parameters specifications support a number of common properties, such as:

  • Label: some text that is shown near the control in the Run Custom Build dialog.

  • Description: some text that is shown below the control containing an explanatory note of the control use.

  • Display: If hidden is specified, the parameter will not be shown in the Run Custom Build dialog, but will be sent to a build; if prompt is specified, TeamCity will always require a review of the parameter value when clicking the Run button (won't require the parameter if build is triggered automatically); if normal is selected, the parameter will be shown as usual.

  • Read-only: if the box if checked, it will be impossible to override the parameter with a different value

  • Type: Currently you can present parameters in following forms:

    • a simple text field with the ability to validate its value using regular expression;

    • a checkbox;

    • a select control;

    • a password field.

The table below provides more details on each control type.

Depending on the specification's type, there are additional settings.

Manually Configuring Parameter Specification



Alternatively, you can manually configure a specification using a specially formatted string with the syntax similar to the one used in service messages (typeName key='value'). For example, for text: text label='some label' regex='some pattern'.

Copying Parameter Specification



If you start editing a parameter that has a specification, you can see a link to its raw value in the "Edit parameter" dialog. Click it to view the specification in its raw form (in the service message format). To use this specification in another build configuration, just copy it from here, and paste in another configuration.

Modifying Parameter Specification via REST API



You can also view/edit typed parameters specification via REST API.