In Azure DevOps I have a Pipeline variable "package version" and I set it using 0.1.3$(Rev:.r)-alpha .
I use that variable to replace the "Version" in the .net core project file.
In the Build tasks the dotnet build give me this error:
so I assume the Pipeline variable cannot use a nested variable.
There is a nother way or a different syntax to do it?
[Edit]
The nested variables should work.
I think the error was the dotnet pack using Automatic package versioning set to "Use the build number" that contain the wrong $(rev:.r) (lowercase!).
Using a custom string for Version in the VS project file gives noise on VS (error if the file is open, warning otherwise) and now the Pipeline Build give me an error on dotnet nuget restore because of the invalid Version.
I decided to use a simple clean version, <Version>0.1.2</Version>, that I can choose and document.
Then I want to find a way to read it in the build pipeline and create a custom variable attaching the Build Revision:
0.1.2$(Rev:.r) => 0.1.2.123
That is the result I want.
I found this: https://marketplace.visualstudio.com/items?itemName=tmarkovski.projectversionasvariable
I'm using it with the default settings.
I'm using the variables it creates to compose a new variable, "package version":
and I use that in the nuget pack task:
but it does not work.
The resulting variable still contain "$(Rev:.r)" not parsed.
I'll try to use again the "Automatic package versioning" and create the build number in the Options...
[Edit 2]
Set the build version number in the Pipeline Build Options worked.
It's not the optimal solution because the Build Number is not parsed and looks awful.
[Solution]
$(Rev:.r) is not available outside Build / Options.
I used $(Build.BuildNumber) and I'm able to create a composed variable:
$(Version.MajorMinor).$(Build.BuildNumber)-alpha
Build.BuildNumber is valorized in Build/Options: $(Build.DefinitionVersion)$(Rev:.r)
Version.MajorMinor is created by the Project Version As Build Variable add-on.
I don't know how to obtain the same result without using a third party component.
I'm glad my extension helped and thanks for the nice review. If you want more control and have a little time to spend to play with PowerShell, you can easily achieve what you want in two steps, without using third party extensions.
Read and parse the .csproj file as XML
Set build variables
Here are couple of links on reading XML files and working with build variables, it's actually pretty easy.
https://www.business.com/articles/powershell-read-xml-files/
VSTS: Pass build/release variables into Powershell script task
[xml]$XmlDocument = Get-Content -Path $env:project_file
echo $XmlDocument.Project.PropertyGroup.Version
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch
Write-Host '##vso[task.setvariable variable=package_version;issecret=true]0.1.2.'
Note: my answer wouldn't fit in a comment, I had to post an answer.
Related
OK, so we're stuck on on-site TFS2015 at the moment. My Nuget Publisher build step is failing with:
##[error]Ambiguous option 's'. Possible values: Source SymbolSource SymbolApiKey.
It appears inside the build step they have put -s instead of -source, and in later versions they've added more commands starting with s. So what are my options?
Write my own in Powershell (Can do, but TFS Build is very clunky for this)
Find wherever this is defined in TFS (hopefully a template .ps file) and fix it there (Anyone know where this is kept?)
Upgrade to a later version of TFS (a fairly large, but perhaps inevitable undertaking)
Somehow override the -s command another way?
????????
Invoke NuGet.exe however you'd like via the Command Line task
If you did #3 (upgrade TFS), you'd find that the PowerShell build task can run an in-line PowerShell script, making it significantly less clunky.
You may be able to extract and modify the task with the tfx command line utility, but I can almost guarantee this will have nasty ramifications when you do eventually upgrade.
I'm adding my answer for details about step 5 maybe it will help team that are still using TFS 2015.
Nuget Publisher seems to use old version, which means "-s" option will not work.
To bypass this situation you can setup your build as follow:
1- Add Nuget Packager Step and specify the the Package Folder value:
2- Add a new step which would copy your artifacts(Note that contents that should be copied must end with nupkg):
3- And Finaly you can just run a command line that will perform the publish operation. In my case we are pushing the whole repository using init command(PackageRepository is the path to our internal feed that we set in we've set in Variables section):
I would like to make my main branch TFS build definitions to treat warnings as errors so that the build fails when the projects are not error free. Since I do not want to activate "treat error as warning" in all project as a default, my first idea was to add a powershell script to my main build definition that substitues false with true in the line <TreatWarningsAsErrors>...</TreatWarningsAsErrors> in all csproj files it finds (something along the line of this). Is there any better/straighter way via some option as part of the build definition settings?
In the build definition specify /p:TreatWarningsAsErrors=True in the MSBuild argument field.
This will override any setting from the csproj files.
Unfortunately, there is no this kind of settings as part of the build definition.
However, you could be able to return warnings and errors from your powershell script using logging commands. With using task.logissue type=error you could fail the build task and then fail the build.
More details you could take a look at this similar question: Is it possible to raise and display build warnings from build steps using TFS 2015
I'm changing the build number of the TeamCity (9.1.4) build with service messages (Build Script Interaction) like this in Powershell:
Write-Host "##teamcity[buildNumber '$version.$arg2']"
This is working absolutely fine.
The problem is that the AssemblyInfoPatcher doesn't want to use this updated build number.
So I tried to use a variable/parameter for it but this also doesn't work.
I defined the following variable "Major.Minor.Patch" as a "Configuration Parameter" or as an "Environment Variables". The AssemblyInfoPatcher is using these variables just fine and changes the file version of my files with the version defined in TeamCity in the build.
If I try to change the variable/parameter with a service message it doesn't work. The AssemblyInfoPatcher is still using the old value.
Example with environment variable
Write-Host "##teamcity[setParameter name='env.Major.Minor.Patch' value='$version']"
Example with configuration parameter
Write-Host "##teamcity[setParameter name='Major.Minor.Patch' value='$version']"
Am I doing something wrong or is it just not possible? The only thing I want is that my files have the same version number as my TeamCity build...
The AsssemblyInfoPatcher runs before any of the build steps (and then runs again to revert your AssemblyInfo files after all your build steps). Thus, if one of your build steps sets Major.Minor.Patch using a service message, it's really too late to the game.
Maybe you could string multiple build configs together. The first config (A) would set up the parameter like you're doing now, and then trigger the second config (B), which would use the AssemblyInfoPatcher. B would have a snapshot dependency on A (in addition to the finish-build trigger) and thus its AssemblyInfoPatcher would be able to refer to %dep.A.Major.Minor.Patch%. This parameter, of course, would already be available when B's AssemblyInfoPatcher runs.
I am deploying web application to azure using TFS CI automated build deployment.
In our config maintain build version like 2014.05.19.1 which is $(Date).$(rev) format.
All I want to update config each time build is deployed.For that I am passing value to 'BuildVersion' parameter in template to powershell script which actually performs publishing to azure.
I tried using $(Date:yyyyMMdd)$(Rev:.r) but it is considered string as it is.
I want to get current build version just like IBuildDetail.BuildNumber
within template.
My question is how to get the build version?
If you are using Invoke Process, instead of passing value for BuildVersion parameter you can directly use 'BuildDetail.BuildNumber' in parameters for process like
String.Format("-BuildNumber ""{0}""",BuildDetail.BuildNumber)
This would give the required build number.
If your PowerShell script is being executed from your TFS build, it should have access to the environment variables specific to the TFS context of the build. If that is the case, you actually don't need to pass the $(BuildVersion) parameter to the script, as it already is accessible to the PS script in the $env:TF_BUILD_BUILDNUMBER environment variable. Try testing something like $env:TF_BUILD_BUILDNUMBER | Out-File "D:\Dev\BuildNumber.txt" in your script. You should hopefully see the file containing your build number after running your build.
(I am assuming you are using a relatively new build process template...one that contains the "Post-Build script path" parameter, such as TfvcTemplate.12.xaml)
Hope this is helpful.
I would recommend that you use the right tool for the right job. The build system, is really only for building (compile & test). We have been using it for other things for years coz we did not have another integrated solution. However Microsoft recently bought InRelease and rebranded as Release Management for Visual Studio 2013. I have successfully integrated this with TFS 2012 as well.
Jenkins official Wiki page for Matrix projects isn't really helping me; so I have a few questions.
We're trying to build a couple of projects that are all essentially the same, just some are being branded differently for our customers. In other words, the software / tests / etc. are all identical, except for some tweaks to turn BrandA into BrandB (or BrandC, etc.)
I figure I should be using a Matrix project to create builds for BrandA, BrandB, etc. While I haven't figured out all my steps yet (including how to rename executables after they're built) I know that I will need to pass the Brand Name to many of my Jenkins Powershell scripts during the build process, and then use that brand n the script.
How do I get these variables into my scripts? Are they automatically passed in to every build step in Jenkins? What is the variable name to use?
Finally, is there a good resource on building these multi-configuration projects in Jenkins? I can't seem to find anything comprehensive online.
If you usually build the job for BrandA and only occasionally for BrandB and BrandC a matrix project may not be what you want. I recommend, instead, using a parameterized job where the brand is a parameter whose default value is BrandA. If the parameter is named BRAND the parameter is accessible in all of the builds and publish steps with ${BRAND} and as an environment variable as %BRAND%.
I refer you to the parameterized build wiki for more details.
Yes, ${BRAND} and %BRAND% should work fine.
If you're using Maven, ${env.BRAND} does this too.
There's a plugin that you can see all Environment Variables that are available to your job/build.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
I'm not aware of that kind of process but I suggest you tu use the Copy project functionnality.
New Job
Copy From existing job
You will have a copy of your Job and you'll be able to setup easily all specific fields.