I have a dynamically created variable inside a CI Pipeline, let's call it "var: $(version.number).$(Date:yyyyMMdd)". I wish to reuse this as a part of the Publish Test Results task in a CD Pipeline so I can link both together and have a valid reference. But I can't fathom how to do this.
This is the yaml for the Publish Test Results task in it's most basic form.
steps:
- task: PublishTestResults#2
displayName: 'Publish Test Results **/TEST-*.xml'
Any pointers will be gratefully accepted.
We could write it out to a json/xml file via power shell task, and publish the file as artifacts. Then read in that file via PowerShell in your release definition.
Build Definition
ConvertTo-Json | Out-File "file.json"
Release Definition
Get-Content "file.json" | ConvertFrom-Json
Also, we could pass the variable from build to release via the extension Variable Tools for Azure DevOps Services.
Steps:
Build Definition and result
Release Definition and result
In addition, I found a blog and save the variable to csv file, you could also refer to Passing variables in VSTS, from Build to Release and between environments.
Related
I am beginner to A and just starting to work in it
What task I must add in project ASP.NET CORE to Azure DevOps Pipelines to pass the build number from the azure devops pipeline to the project code
Client.Shell.csproj:
<MinimumRequiredVersion> 4.60.0825.700 </MinimumRequiredVersion>
<ApplicationRevision> 716 </ApplicationRevision>
<ApplicationVersion> 4.60.0825.% 2a </ApplicationVersion>
https://i.stack.imgur.com/BXyHm.png
You can do something like this, Replace "1.2.3" with your build parameter.
dotnet publish ./MyProject.csproj /p:Version="1.2.3" /p:InformationalVersion="1.2.3-qa"
Look at this https://github.com/dotnet/docs/issues/7568
When a pipeline runs, it usually performs get sources action first. So you just need to map the correct project path, then the pipeline will get entire project to the Agent's working folder.
To update the version in .csproj file, and to pass the build number from the azure devops pipeline, you can check Assembly Info extension, and use the variable $(Build.BuildNumber) in the version field.
This extension can update project AssemblyInfo files and .Net Core / .Net Standard project files .csproj. For detailed instructions on how to configure the extension please see the following link:
https://github.com/BMuuN/vsts-assemblyinfo-task/wiki/Versioning
If you want to update the file in repo, you still need to run git push command to push the changes to the repo.
I have a series of build pipelines setup by someone no longer available. The Visual Studio Build steps all have this in their MSBuild Arguments field:
/p:DeployOnBuild=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" /p:PublishProfile="$(build.sourcesdirectory)\RestApi\Properties\PublishProfiles\VSTS-InPlacePublish.pubxml"
This produces a release build but I would like to avoid having to specify the build profile within the source repo of the application; I would like to remove the publish profile and get the same output simply by using the appropriate parameters in the build step.
Is this possible and if so, how?
I'm using Drone 0.5. Our build process compiles code to generate an artifact that is deployed to an artifact repository. I need a reference to this artifact for use in later build steps.
Is there a way to pass arbitrary data between build steps? Maybe through environment variables?
I don't know about creating env variables during the build process and persisting them, but the file system is definitely preserved. So you could put whatever data you need into a file for the next step.
I have a TeamCity build which uses msbuildbootstrap to run msbuild. I want to run the same msbuild command on my local machine, but I don't know what parameters TeamCity is passing it. The logs don't say.
[Step 1/3] Starting: D:\BuildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:D:\BuildAgent\work\e8f57dfa2eca8e8c /msbuildPath:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
[14:10:12][Step 1/3] in directory: D:\BuildAgent\work\e8f57dfa2eca8e8c
[14:10:14][Step 1/3] depot\Build\Scripts\release.build.teamcity: Build target: PublishRelease (1m:10s)
[14:10:14][depot\Build\Scripts\release.build.teamcity] PublishRelease (1m:10s)
[14:10:14][PublishRelease] CreateCustomBuildLabelTask (1s)
[14:10:15][CreateCustomBuildLabelTask] Creating custom build label from TeamCity build number 7375.
[14:10:15][CreateCustomBuildLabelTask] Generated build label is 2016.02.01.ReleaseCandidate
[14:10:15][PublishRelease] CopyBuildArtifactsTask (5s)
How can I exactly replicate the parameters TeamCity passes to msbuild? Is there any documentation for msbuildbootstrap?
That's a tough question, because TeamCity does not only send a list of properties as an input for the MsBuild command. It creates a list of environment variables that will be taken into account by MsBuild itself as properties.
You can find the defined environment parameters in the "Parameter"s section of your build configuration in TeamCity. They are referenced as "System Properties (system.)".
Once a build has been executed, you can find again the list of system properties in the build result tab named "Parameters" under "System properties".
As a build manager, I don't like this situation, as it can be pretty hard to reproduce a build on a local machine. We use too many system properties today, only specified in TeamCity. I want to shift us to a clear API for executing our builds.
In a TFS2013 build, in the Post-build path of the build definition, I call a PowerShell script which need to get the path of the Solution built just before.
But the SolutionPath varibale is not provided in the Environment Variables and we can't pass this variable in the Post-Build Arguments in the Definition Build.
Have you a tip for that without modify the build template ?
Thank you.
The reason there isn't a SolutionPath variable in the tfbuild , in my opinion, is because there aren't any obligation you will only build one solution in your build process.
In order to run the script after the solution done with the build you could add an After..sln.targets and specify a task to do as you please (powershell task inside msbuild)
http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
MSBuild - Project-specific targets for solution does not work
Another option is: in case you want the relative path under your root folder, you could just use the $env:TF_BUILD_SOURCESDIRECTORY inside your script, which will lead you to the \src folder of your build
Get-ChildItem $env:TF_BUILD_SOURCESDIRECTORY | Where-Object FullName -Like "*.sln" | foreach {$_.FullName}