For example, within Set-BuildNumberWithGitCommitDetail we have the parameter sendTeamCityServiceMessage which, as it suggests updates the build number within the executing TeamCity build configuration to reflect that created by OneBuild, as so:
if ($sendTeamCityServiceMessage -eq $true)
{
#Forces TeamCity to use a specific buildNumber (substituting in its build counter as we only use {0} in the TeamCity build number format
#See http://confluence.jetbrains.com/display/TCD7/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber
#and http://youtrack.jetbrains.com/issue/TW-18455 for more details.
Write-Host "##teamcity[buildNumber '$major.$minor.$buildCounter.$revision']"
}
Although this is benign for other CI servers it's noise, also the solution isn't so simple with other CI servers, such as AppVeyor, where you need to call their PowerShell module during the build, see http://www.appveyor.com/docs/build-worker-api#update-build-details
This issue is to look at moving CI server specific commands out in to support NuGet packages, such at OneBuild.TeamCity and OneBuild.AppVeyor, alowing us to keep the OneBuild NuGet package clean and CI server agnostic.
For example, within
Set-BuildNumberWithGitCommitDetailwe have the parametersendTeamCityServiceMessagewhich, as it suggests updates the build number within the executing TeamCity build configuration to reflect that created by OneBuild, as so:Although this is benign for other CI servers it's noise, also the solution isn't so simple with other CI servers, such as AppVeyor, where you need to call their PowerShell module during the build, see http://www.appveyor.com/docs/build-worker-api#update-build-details
This issue is to look at moving CI server specific commands out in to support NuGet packages, such at
OneBuild.TeamCityandOneBuild.AppVeyor, alowing us to keep theOneBuildNuGet package clean and CI server agnostic.