チェーンのビルドでパラメーターを使用する

Input and output parameters

Build configurations and pipelines allow you to create parameters of two types: input and output.

Both of them are manually created name/value pairs. The key difference lies in intended use cases and accessibility settings.

入力パラメーター

Input parameters are designed to be consumed by the same configuration/pipeline that defines them. For example, an input parameter that stores a default branch name and referenced in VCS ルート設定 . This value is of no use for other configurations and thus, should not be visible to them.

出力パラメーター

Output parameters are configured in one build configuration/pipeline, but can be accessed by another via a snapshot or artifact dependency. For example, a build configuration that builds a Docker image can write this image name to its parameter. The parameter is later used by a downstream configuration that deploys this image to a registry.

出力パラメーターは、既存のパラメーターをそのまま共有したり、変更されたパラメーターや定数を共有したりできます。

outputParams { // Expose predefined parameter as is param("originConfName", "%system.teamcity.buildConfName%") // Expose modified parameter value param("buildNumber", "Build %\system.build.number%") // Expose input parameter as is param("name", "%customInputParam%") // Expose static value param("number", "54") }

Read parameters of upstream objects

Jobs can share their parameters with other jobs of the same pipeline only if they are linked in a sequence. Similarly, pipelines and configurations can access each other's parameters only when linked in a build chain.

Expose all input parameters of a configuration

In build configurations, the 新しい出力パラメーターを追加 dialog has two options: enter the value manually or share an existing input parameter as is. Select a required input parameter, and TeamCity will create an output parameter with the %inputParameter% value.

If the すべてのパラメーターは他のビルド構成でも利用可能 setting is checked, you do not need to share each input parameter individually. All of them are automatically exposed and can be referenced via the dep.<config-ID>.<parameterName> syntax.

This setting is enabled by default for backward compatibility. However, we strongly recommend you to do the following:

1. 入力パラメーターが他の構成で使用されているすべてのケースを確認します。

2. 共有し続けたい入力パラメーターを新しい出力パラメーターで参照して公開します。

3. すべてのパラメーターは他のビルド構成でも利用可能設定を無効にします。

そうすることで、構成のメンテナンスが容易になります。dep... 構文を介してこれらのパラメーターを使用した下流の構成を誤って壊すことなく、必要に応じて入力パラメーターを編集および削除できます。さらに、共有されることが意図されていない非表示パラメーターを保持することで、セキュリティが強化されます。

Override parameters of upstream objects

A downstream configuration/pipeline can read parameters from an upstream configuration/pipeline via dep.<source-object-ID>.<parameter-name> . Add the override.dep. prefix to do the opposite: override a value of an upstream parameter from a directly or indirectly dependent entity.

The following example illustrates two objects exchanging parameter values:

• The build chain contains two objects: an upstream pipeline and a downstream build configuration.

• The pipeline declares an input parameter with the default value foo . When the pipeline runs on its own, this value is used in the build script.

• When the pipeline runs as part of a build chain (triggered by the configuration's snapshot dependency), the downstream configuration overrides this parameter and sets it to bar .

• The pipeline output parameter references the input parameter, so it reports the updated value as well.

In other words, the downstream configuration writes bar to the pipeline input via override.dep. , the pipeline exposes it through its output parameter, and the downstream configuration can then read it back via dep. .

The types of the sender and receiver do not matter. In this example, a build configuration overrides a pipeline parameter, but the same syntax and behavior apply to any combination: pipeline to build configuration, pipeline to pipeline, or build configuration to build configuration.

'reverse.dep.' parameters

The override.dep.<target-ID>.<parameter-name> syntax was introduced in TeamCity 2026.1. In earlier versions, upstream parameters were modified with the similar reverse.dep.<target-ID>.<parameter-name> syntax.

reverse.dep. is still supported, but we recommend override.dep. because its behavior is simpler and more predictable.

• Unlike override.dep. , reverse.dep. does not resolve parameter references and passes them as is, which can make upstream configurations or pipelines incompatible with some build agents.

• reverse.dep. is also more invasive: if a target configuration or pipeline has no matching parameter, TeamCity creates one. By contrast, override.dep. only updates existing parameters and ignores entities without a matching parameter. This is also worth noting since adding new parameters nullifies the " 適切なものがあれば、新しいビルドを実行しないでください " snapshot dependency policy, so upstream builds will never be reused.

• reverse.dep. uses more complex conflict resolution. When multiple entities modify the same parameter, TeamCity first gives priority to the configuration or pipeline that runs last, just as it does for override.dep. . If the conflicting editors are on the same level, TeamCity compares target ID specificity: the parameter with the most specific ID wins.

  Config A +-----------------------------------------------------------+ | person = "Mary" | +-----------------------------------------------------------+ ┌────────────────────├───────────────────────┐ ▼ ▼ ▼ Config B Config C Config D +----------------+ +----------------+ +----------------+ | reverse.dep. | | reverse.dep. | | reverse.dep. | | ConfigA.person | | Conf*.person | | *.person | | = John | | = Mike | | = Jane | +----------------+ +----------------+ +----------------+ └─────────────────────├───────────────────────┘ Run all ▼ +-----------------------------------------------------------+ | composite configuration | | depends on: ConfigB, ConfigC, ConfigD | +-----------------------------------------------------------+ Config B: fully clarified target ID Config C: ID partially replaced with a wildcard Config D: wildcard instead of target ID Final value in ConfigA: "John" (Config B)

  Finally, if the conflicting edits come from same-level entities with equally specific IDs, TeamCity leaves the target parameter unchanged and adds a conflict.<sender_config_ID>.paramName parameter for each unique conflicting value.