Setting a TeamCity Configuration or System parameter from a PowerShell Build Step

I am using PowerShell to generate several values which requires some sophisticated processing logic.

However, I have several steps in my build configuration and I want to avoid having to re-generate this value in each of my PowerShell scripts each time.

Therefore, is it possible to return a value from my PowerShell script and store it in a TeamCity Configuration or System parameter?

For example, if I generate a value from my PowerShell script in Build Step 1, can I return it and store it in TeamCity so that it can be used by any subsequent TeamCity Build Steps (Steps 2, 3, 4 etc.)?

If so, how do I accomplish this?

Please advise.


Comment actions Permalink

Hi Samir,

Yes, you can use service messages to dynamically update build parameters of the build from a build step.
Please note that the changed build parameters will be available in the build steps following the modifying one.

Comment actions Permalink

So how exactly would I update that from a PowerShell script?  Could you provide me with an example?

Would I basically be doing the following:


"##teamcity[system.myparameter name='ddd' value='fff']"

Please clarify.

Comment actions Permalink

For example to make parameter "var" equals "10" use the following script:

write-host "##teamcity[setParameter name='var'
Comment actions Permalink

I have problems using this functionality.

I want a environment-Variable set to the Value of "$newVersion" to use it in subsequent build steps and the "buildNumber" set to it, to have a consistent build-Identifier.

My powershell code:

$newVersion = (get-item "%env.ExternalTrunkLatestBuildPath%").VersionInfo.ProductVersion;
Write-Host "##teamcity[setParameter name='env.NewExternalTrunkProductVersion' value='$newVersion-%build.counter%']";
Write-Host "##teamcity[buildNumber '%env.NewExternalTrunkProductVersion%']";
echo %env.NewExternalTrunkProductVersion%;


"$newVersion" has a valid value, but I'm not able to pipe it "into" TeamCity.

Comment actions Permalink

Got it:

$newExternalVersion = (get-item "%env.ExternalTrunkLatestBuildVersionPath%").VersionInfo.ProductVersion;
Write-Output "##teamcity[buildNumber '$newExternalVersion-%build.counter%']";
Comment actions Permalink

I've been trying to use this same technique to set the Build number format.   My first build step is:

$formatNow = [DateTime]::Now.ToString("MMdd")
Write-Output "##teamcity[setParameter name='' value='$formatNow']"

The build number format is set to:

After the build when I look at the Parameters, under "User Defined Parameters" it shows my with a value of <empty>, but later under "Actual Parameters on Agent" a correct value is set.  But the build number is not updated to include this new value.   

Any ideas?


Comment actions Permalink

You have to set the buildnumber, after you altered your "", but you don't even need this Variable, if you use it only in this build.

The format, that is set within the build configuration, will be processed, before your script has been executed.

This should work:

The build number format in the build configuration set to: %build.counter% (this is a temporary value, that will be overwritten by your script!)

$formatNow = [DateTime]::Now.ToString("MMdd")

Write-Output "##teamcity[buildNumber '17.11.%build.counter%.$formatNow']";
Comment actions Permalink

Is there a way to persist the parameter changes so they are available for subsequent builds?

Preferably one that doesn't involve having to go to the REST API using CURL.

Comment actions Permalink

Devops - Are you opposed to using REST API altogether or do you just not want to use CURL? Using the REST API would typically be the preferred method for making persistent changes to a build configuration from a build step for most cases. However, you may also be able to change these settings if you're using Versioned Settings to store your configuration settings in a VCS.

TeamCity allows the two-way synchronization of the project settings with the version control repository. Supported VCSs are Git, Mercurial, Perforce, Subversion, and Azure DevOps Server (formerly TFS).

You can store settings in the XML format or in the Kotlin language and define settings programmatically using the Kotlin-based DSL.

When you enable two-way settings' synchronization:

  • Each administrative change made to the project settings in the TeamCity web UI is committed to the version control; the changes are made noting the TeamCity user as the committer.

  • If the settings change is committed to the version control, the TeamCity server will detect the modifications and apply them to the project on the fly.
    Before applying the newly checked-in settings, validation constraints are applied. If the constraints are not met (that is, the settings are invalid), the current settings are left intact and an error is shown in the UI. Invalid settings are those that cannot be loaded because of constraints, for instance, a build configuration referencing a non-existing VCS root, or having a duplicate ID or a duplicate name.


Please sign in to leave a comment.