I'm trying to publish a file (Helloworld.txt) to my Universal Packages directory to pass on to a different stage within my Release Piepline (using UniversalPackages#0).
I cannot for the life of me figure out how to make it work.
I'm trying to follow this KB but it leaves me confused:
https://learn.microsoft.com/en-us/azure/devops/pipelines/artifacts/universal-packages?view=azure-devops&tabs=yaml
For example, I can't determine what vstsFeedPublish is and don't know if vstsFeedPackagePublish can be a new name I make up on the spot or if it is actually the name of an existing file/folder.
What "path" am I entering incorrectly that's making it fail?
Stage Deployment Steps:
Helloworld Output to TXT:
cd $(Build.ArtifactStagingDirectory)
"$(System.DefaultWorkingDirectory)/Helloworld Build/Helloworld EXE Folder/Helloworld.exe" >> WriteLineOutput.txt
I cd into $(Build.ArtifactStagingDirectory) first because that is the default folder UniversalPackages#0 looks to publish files, so I want WriteLineOutput.txt to be generated there.
Publish Output TXT to Universal Dir (YAML):
steps:
- task: UniversalPackages#0
displayName: 'Publish Output TXT to Universal Dir'
inputs:
command: publish
vstsFeed: '0a3a9abd-83fd-495f-967b-e986c523f2d2'
vstsPackageVersion: 1
vstsFeedPublish: '0a3a9abd-83fd-495f-967b-e986c523f2d2'
vstsFeedPackagePublish: 'writelineoutput-txt'
versionOption: minor
packagePublishDescription: 'TXT output from Helloworld.exe'
Working Directory Structure:
"Publish Output TXT to Universal Dir" Task Output:
2019-12-02T03:35:35.2264352Z ##[section]Starting: Publish Output TXT to Universal Dir
2019-12-02T03:35:35.2381247Z ==============================================================================
2019-12-02T03:35:35.2381328Z Task : Universal packages
2019-12-02T03:35:35.2381359Z Description : Download or publish Universal Packages
2019-12-02T03:35:35.2381412Z Version : 0.160.1
2019-12-02T03:35:35.2381461Z Author : Microsoft Corporation
2019-12-02T03:35:35.2381490Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks
2019-12-02T03:35:35.2381520Z ==============================================================================
2019-12-02T03:35:36.0651445Z SYSTEMVSSCONNECTION exists true
2019-12-02T03:35:36.6058302Z Downloading: https://0t3vsblobprodcus362.vsblob.vsassets.io/artifacttool/artifacttool-win10-x64-Release_0.2.128.zip?sv=2017-04-17&sr=b&sig=tHZQU3V2DuXcC0Y1xnmzB7Zw7kMdjJSijWVDiztc9UE%3D&spr=https&se=2019-12-02T04%3A35%3A37Z&sp=r&P1=1575261037&P2=11&P3=2&P4=LS6Ffab5P%2bb8Q9r3aGsGLlK9ELRD6bRxxlTkDc5aEc8%3d
2019-12-02T03:35:39.3862184Z Caching tool: ArtifactTool 0.2.128 x64
2019-12-02T03:35:40.4414172Z SYSTEMVSSCONNECTION exists true
2019-12-02T03:35:41.4415128Z Publishing package: writelineoutput-txt, version: 0.1.0 using feed id: 65dc653c-5c3b-771c-b308-34b199d8fcee, project: null
2019-12-02T03:35:41.4469092Z [command]C:\hostedtoolcache\windows\ArtifactTool\0.2.128\x64\ArtifactTool.exe universal publish --feed 65dc653c-5c3b-771c-b308-34b199d8fcee --service https://vsrm.dev.azure.com/sawtooth-capstone/ --package-name writelineoutput-txt --package-version 0.1.0 --path D:\a\r1\a\$(Build.ArtifactStagingDirectory) --patvar UNIVERSAL_PUBLISH_PAT --verbosity None --description "TXT output from Helloworld.exe"
2019-12-02T03:35:44.0492154Z {"#t":"2019-12-02T03:35:43.3152933Z","#m":"ApplicationInsightsTelemetrySender will correlate events with X-TFS-Session 23e076ea-5122-4c06-b92a-2aef5974defd","#i":"8778ba0f","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.315Z"}
2019-12-02T03:35:44.0493421Z {"#t":"2019-12-02T03:35:43.7170274Z","#m":"Ensuring that the package does not yet exist...","#i":"40e01e14","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.717Z"}
2019-12-02T03:35:44.0494251Z {"#t":"2019-12-02T03:35:43.8900269Z","#m":"Package does not yet exist","#i":"c781eca5","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.890Z"}
2019-12-02T03:35:44.0494769Z {"#t":"2019-12-02T03:35:43.8913512Z","#m":"Pushing content...","#i":"3aa40378","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.891Z"}
2019-12-02T03:35:44.0495859Z {"#t":"2019-12-02T03:35:43.9060246Z","#m":"DedupManifestArtifactClient will correlate http requests with X-TFS-Session 23e076ea-5122-4c06-b92a-2aef5974defd","#i":"09a6f3ce","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.906Z"}
2019-12-02T03:35:44.0496478Z {"#t":"2019-12-02T03:35:44.0301714Z","#m":"The path provided is invalid.","#i":"05178f7d","#l":"Error","SourceContext":"ArtifactTool.Program","UtcTimestamp":"2019-12-02 03:35:44.030Z"}
2019-12-02T03:35:44.0776082Z ##[error]Error: An unexpected error occurred while trying to push the package. Exit code(16) and error({"#t":"2019-12-02T03:35:43.3152933Z","#m":"ApplicationInsightsTelemetrySender will correlate events with X-TFS-Session 23e076ea-5122-4c06-b92a-2aef5974defd","#i":"8778ba0f","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.315Z"}
{"#t":"2019-12-02T03:35:43.7170274Z","#m":"Ensuring that the package does not yet exist...","#i":"40e01e14","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.717Z"}
{"#t":"2019-12-02T03:35:43.8900269Z","#m":"Package does not yet exist","#i":"c781eca5","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.890Z"}
{"#t":"2019-12-02T03:35:43.8913512Z","#m":"Pushing content...","#i":"3aa40378","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.891Z"}
{"#t":"2019-12-02T03:35:43.9060246Z","#m":"DedupManifestArtifactClient will correlate http requests with X-TFS-Session 23e076ea-5122-4c06-b92a-2aef5974defd","#i":"09a6f3ce","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.906Z"}
{"#t":"2019-12-02T03:35:44.0301714Z","#m":"The path provided is invalid.","#i":"05178f7d","#l":"Error","SourceContext":"ArtifactTool.Program","UtcTimestamp":"2019-12-02 03:35:44.030Z"})
2019-12-02T03:35:44.0789627Z ##[error]Packages failed to publish
2019-12-02T03:35:44.0898947Z ##[section]Finishing: Publish Output TXT to Universal Dir
Key Lines:
2019-12-02T03:35:44.0496478Z {"#t":"2019-12-02T03:35:44.0301714Z","#m":"The path provided is invalid.","#i":"05178f7d","#l":"Error","SourceContext":"ArtifactTool.Program","UtcTimestamp":"2019-12-02 03:35:44.030Z"}
2019-12-02T03:35:44.0776082Z ##[error]Error: An unexpected error occurred while trying to push the package. Exit code(16) and error({"#t":"2019-12-02T03:35:43.3152933Z","#m":"ApplicationInsightsTelemetrySender will correlate events with X-TFS-Session 23e076ea-5122-4c06-b92a-2aef5974defd","#i":"8778ba0f","SourceContext":"ArtifactTool.Commands.UPackPublishCommand","UtcTimestamp":"2019-12-02 03:35:43.315Z"}
EDIT:
Well, I read it's best practice to use the Build pipeline to publish artifacts and the Release pipeline to run/test them, so I decided to just publish the artifact from the Build pipeline instead of trying to make the same Helloworld.txt again during the Release pipeline. But I'm willing to take the inevitable downvotes if someone can help me figure out how to publish new files created in the Release pipeline into the Universal packages directory.
I'd better suggest you call exe to generate the txt file in Build. Then publish them as artifacts to release pipeline. Then you can easily pick the HelloWord.txt file in Release pipeline.
This task can be used both in Build and Release pipeline. The difference between apply this task in Build and release just be the Path to file(s) to publish value which you very confused.
For Release pipeline:
If what you want is publish the HelloWord.txt into package, just click , and then select the corresponding file HelloWord.txt from it.
So, what its value should be $(System.DefaultWorkingDirectory)/{Source alias}/{artifact name}/s/HelloWorld.txt.
Note: This way is applied when you put the txt generated in Build pipeline, and then publish them as artifact and used in release pipeline.
Similar in Build pipeline, you can also select the file from that button. For its YAML format, just input the file name like:
inputs:
command: publish
publishDirectory: 'azure-pipelines.txt'
vstsFeedPublish: '*****'
vstsFeedPackagePublish: merlin
versionOption: custom
versionPublish: 0.0.1
packagePublishDescription: published in 2019/12/2
If azure-pipelines.txt file is under a folder, just input it as a {folder name}/azure-pipelines.txt.
In your issue, if you want to put the file generate and the package publish both in Build pipeline. Since I do not very clear know how's your HellowWorld.exe script like. The location of HelloWorld.txt is decided by your script. If you did not define the generated file location in script, as default, this txt file path should same with exe. According to the pic you shared, seem its path is HelloWorld EXE Folder/HelloWorld.txt. I suggest you can use private agent firstly to run this Build to confirm its(.txt) path.
vstsFeedPublish should be the existing feed you have created in your project. Here it can not be the new name that dose not exist before the pipeline executed.
vstsFeedPackagePublish is the package name you want it stored in feed. For me as sample, here I name it as merlin. After the release finished:
You can specify a new name or use the exists one. Use a new name means create a new package in Feed, and use the exists one just means the version incremental.
I created a new build with Azure Pipelines (Azure DevOps) and it worked really well.
Usually, you use $(Rev:.r) to get the revision in the build. Unfortunately, it seems the variable isn't replaced/set in the build steps. The only place where you can use it is the name: property in the YAML document.
Now I set it in the name and extract it in some PowerShell, which isn't necessary if you can get it via an environment variable.
How do I get the Revision (like $(Rev)) in the new builds (outside of the name: property in the YAML document)?
(The Build Agents running on-premise, inside Docker - but this shouldn't affect the things above)
You can't get the revision number without parsing, it is not stored as a separate field somewhere or in an environment variable.
The $(Rev:.r) portion instructs Azure DevOps to come up with the first number that makes the build number unique (and, in that specific example, put a dot in front of it).
Like you said, the only way is to use PowerShell script to get the value:
$buildNumber = $Env:BUILD_BUILDNUMBER
$revision= $buildNumber.Substring($buildNumber.LastIndexOf('.') + 1)
Edit:
You can install the Get Revision Number extension that does it.
Another possible solution to the above problem could be to use counter expression for ex: we difine the variable and use it in a task to build nuget package.
variables:
counterVar: $[counter($(versionVariable),0)]
.......
- task: CmdLine#2
inputs:
script: >
nuget pack ClassLibrary1/ClassLibrary1.csproj
-OutputDirectory $(Build.ArtifactStagingDirectory)
-NonInteractive
-Properties Configuration=release
-Version $(versionVariable).$(counterVar)
-Verbosity Detailed
-IncludeReferencedProjects
Here versionVariable is a custome variable defined in pipelines->variables.And the seed value is 0(2nd param to counter).
It works as below
Let's assume the versionVariable is 1.19
Build Run 1 counterVar will be 0.
Build Run 2 counterVar will be 1.
Now say we change the versionVariable to 1.20
Build Run 3 counterVar will be 0.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops
Check the counter expression in above link it reset its value for diff prefix.
P.S. Benefit of using counter over $(Rev:r) is that it can start from 0 unlike $(Rev:r)
I want to update the version number of my .exe file using Update Assembly Info plugin.
I am using the following configuration:
But, I keep getting an error
'$(Date:yyyy.MM.dd)$(Rev:.r)' is not a valid parameter for attribute 'AssemblyVersion'
The $(Date:yyyy.MM.dd) and $(Rev:.r) can’t be used as the build-in variable, it can be used in Build number format (Options tab).
The workaround is that:
Include $(Rev:.r) in Build number format, such as $(date:yyyyMMdd)$(rev:.r)
Add PowerShell task to add a new variable (Arguments: -bn $(Build.BuildNumber)
Script:
param(
[string]$bn
)
$d=Get-Date -Format "yyyyMMdd"
$r=$bn.split("{.}")[-1]
Write-Host "##vso[task.setvariable variable=currentVersion]$d$r"
Then use currentVersion variable in subsequent tasks, such as Update Assembly task.
In previous versions of TFS (before 2015), there was a build environment variable for PowerShell called: TF_BUILD_DROPLOCATION, which gave the The location of the drop:
https://msdn.microsoft.com/library/hh850448%28v=vs.120%29.aspx.
I can't find the equivalent variable in TFS 2017.
What is the best practice to get it?
With Build agent tasks taking over things are different. What I do to see the various build environment variables is to make a simple batch file containing this:
SET C:\temp\EnvVars.txt
That'll produce a quick list of what is available.
Here's what I see with the TFS 2017 build agent:
agent.jobstatus=Succeeded
AGENT_BUILDDIRECTORY=C:\Agent\_work\2
AGENT_HOMEDIRECTORY=C:\Agent
AGENT_ID=2 AGENT_JOBNAME=Build
AGENT_JOBSTATUS=Succeeded
AGENT_MACHINENAME=BUILDMACHINE
AGENT_NAME=BUILDMACHINE
AGENT_OS=Windows_NT
AGENT_ROOTDIRECTORY=C:\Agent\_work
AGENT_SERVEROMDIRECTORY=C:\Agent\externals\vstsom
AGENT_TEMPDIRECTORY=C:\Agent\_work\_temp
AGENT_TOOLSDIRECTORY=C:\Agent\_work\_tool
AGENT_VERSION=2.122.1
AGENT_WORKFOLDER=C:\Agent\_work
BUILD_ARTIFACTSTAGINGDIRECTORY=C:\Agent\_work\2\a
BUILD_BINARIESDIRECTORY=C:\Agent\_work\2\b
BUILD_BUILDID=2036
BUILD_BUILDNUMBER=Database Build_20190708.2
BUILD_BUILDURI=vstfs:///Build/Build/2036
BUILD_CONTAINERID=2281
BUILD_DEFINITIONNAME=Database Build
BUILD_DEFINITIONVERSION=17
BUILD_QUEUEDBY=Smith, John
BUILD_QUEUEDBYID=8c588342-b87a-40cb-9b8c-a0ed10b57a3f
BUILD_REASON=Manual
BUILD_REPOSITORY_CLEAN=false
BUILD_REPOSITORY_GIT_SUBMODULECHECKOUT=False
BUILD_REPOSITORY_ID=$/
BUILD_REPOSITORY_LOCALPATH=C:\Agent\_work\2\s
BUILD_REPOSITORY_NAME=Collection
BUILD_REPOSITORY_PROVIDER=TfsVersionControl
BUILD_REPOSITORY_TFVC_WORKSPACE=ws_2_2
BUILD_REPOSITORY_URI=http://TFSSERVER:8080/tfs/Project/
BUILD_REQUESTEDFOR=Smith, John
BUILD_REQUESTEDFOREMAIL=John.Smith#Mailinator.com
BUILD_REQUESTEDFORID=7a588222-b66a-40ee-9b2a-a0ba10b12a3f
BUILD_SOURCEBRANCH=$/Collection/Project/Code
BUILD_SOURCEBRANCHNAME=Code
BUILD_SOURCESDIRECTORY=C:\Agent\_work\2\s
BUILD_SOURCEVERSION=9811
BUILD_SOURCEVERSIONAUTHOR=Smith, John
BUILD_SOURCEVERSIONMESSAGE=Added missing permission
BUILD_STAGINGDIRECTORY=C:\Agent\_work\2\a
You can list all Environment Variables with the following command:
get-childitem ENV:\
I am assuming you could create a simple build job that executes this and then look at the console output to determine what the name is of the Environment Variable you need.
I am running build on Azure with a custom build agent (using Unity3d to be precise) I generate output of the build within a .txt file on the build machine and would like to include content within work items created during build.
Example:
Unity build fails and an error is logged to Build.log.
New bug is created with reference to build and the error message from the
logfile
Right now I am using a powershell script
$content = [IO.File]::ReadAllText("$(Build.Repository.LocalPath)\BuildProjectPC\Build.log")
Write-Host "##vso[task.setvariable variable=logContent;]$content"
To format the bug i use System.Description = $logContent but the content of the variable from PS does for some reason not end up in the bug item (it just contains "$logContent").
Any idea or direction how to fix this, respectively how to feed info back into vsts?
The variable value that used for creating work item is initialized before running build steps, so you can’t specify a dynamic variable or change the variable value during the build step that used for creating work item.
You can follow up these steps to verify it:
Open your build definition > Variable > Add a new variable (e.g. logContent, value: oldValue)
Select Options > Check Work Item on Failure > Additional Fields > System.Title $(logContent)
Add PowerShell build step: Write-Host "$(logContent)"
Add PowerShell build step: Write-Host "##vso[task.setvariable variable=logContent;]newValue"
Add PowerShell build step: Write-Host "$(logContent)"
Add PowerShell build step: [Environment]::Exit(1)
The log result:
Step 3 output oldValue
Step 5 output newValue
The created work item title oldValue.
The workaround for your requirement is that, you can create a work item and associated to build through PowerShell with Rest API (add PowerShell step at the end of other steps and Check Always run option).
Associate work item to build:
Request Type: Patch
Request URL: https://[your vsts account].visualstudio.com/DefaultCollection/_apis/wit/workitems/[work item id]?api-version=1.0
Content-Type:application/json-patch+json
Body:
[
{
"op": "add",
"path": "/relations/-",
"value": {
"rel": "ArtifactLink",
"url": "vstfs:///Build/Build/[build id]",
"attributes": {
"comment": "Making a new link for the dependency"
}
}
}
]
You can refer to this blog for PowerShell scripts to create and associate work item.
Build association with work Items in vNext
In the Additional Fields you need to reference the build/release definition variable with the following notation: $(logContent)
as shown here below: