That’s right. We currently don’t support publishing artifacts from a release.

##vso[task.uploadfile] can be used to upload files to release. We don’t have plans to support uploading folder/artifacts from release in near future.

We also have a need for this ability. We are generating a report (an html performance test) after a deployment step in a release definition and would like to be able to upload that html file to the release for linking to a dashboard eventually but for now just for auditing purposes. We considered shaping the data to look like a test, but we really need the ability to upload the html file, not xml.

@GitHubSriramB & @ericsciple - I know it’s been a year, but I ran into the same scenario again (forgetting that artifact.upload does not work from the release side. The error is not clear though as @GitHubSriramB last message mentioned.

I get this:

2018-05-10T01:40:06.0800268Z ##[error]Unable to process command ‘##vso[artifact.upload containerfolder=AXLogs;artifactname=AXLogs;]D:\AWK’ successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296) 2018-05-10T01:40:06.0814554Z ##[error]Value cannot be null.

So is there anyway to upload files back during a release?

Part of my release to production process is running import commands that produce logs. I’d like to upload/associate the various log files with the releases. I don’t want to dump the log file contents back to the release if I can keep them in their files.

Has anyone got a workaround for this not working on release? I have a file generated that’s specific to the first agent phase of a release, and I need to pass it to a second agent phase.

If anyone is interested, I created an extension that allows to publish files to the logs (via the same mechanic as @joakimglysing is mentioning) and also offers a task to download those artifacts again in a later stage.

It can be found on the Marketplace and on github.

@dci-aloughran @Boaz101 @brownbl1 I wrote this PowerShell function as a work-around that I just call from either a Build/Release and it should upload a directory to either.

The main difference being for Releases using “##vso[task.uploadfile]” and for builds “##vso[artifact.upload…”, where it seems like builds would allow a directory upload and releases would allow individual file upload.

So for releases, I just loop through a provided directory. Works well enough for my purposes.

function KWVSTSUploadDir()
{
	[CmdletBinding()] 
	param 
	( 
	[Parameter(Mandatory=$true, Position=0)] 
	[string]$Directory,
	[Parameter(Mandatory=$false, Position=1)] 
	[string]$ContainerFolder = "Misc",
	[Parameter(Mandatory=$false, Position=2)] 
	[string]$ArtifactName = "Misc"
	)

	begin {
		Write-Host "Uploading...$($Directory)"
	}
	process {
		switch ($env:SYSTEM_HOSTTYPE)
		{
			'release' {
				Write-Host "Detected Release...uploading files individually..."
				
				foreach ($file in (Get-ChildItem -Path $Directory))
				{
					Write-Host "Release: Uploading $($file.FullName)"
					Write-Host "##vso[task.uploadfile]$($file.FullName)"
				}
			}
			'build' {
				Write-Host "Detected Build...uploading folder..."
				foreach ($file in (Get-ChildItem -Path $Directory))
				{
					Write-Host "Build: Uploading $($file.FullName)"
				}
				Write-Host "##vso[artifact.upload containerfolder=$ContainerFolder;artifactname=$ArtifactName;]$($Directory)"
			}
		}
	}
	end {
		Write-Host "Finished uploading for $($env:SYSTEM_HOSTTYPE)"
	}	
}

Reopening to answer question for @dci-aloughran and @Boaz101

@GitHubSriramB - can you confirm whether publishing from release is planned?

I’m using Cypress (end 2 end testing) that generates screenshots, these are attachet to the zip generated from release-pipeline-button “Download all logs” in this way:

Powershell-task (inline):

Compress-Archive -Path "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -DestinationPath "$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots" -Force
Write-host "##vso[task.uploadfile]$(System.DefaultWorkingDirectory)/TestFolder/ScreenShots.zip"

Publishing log files from a release would be super useful. The only workaround would be to feed them to the built in logging. However that is much slower when the logs are large.

Is there any update on this? “uploadFile” uploads with the logs of the release definition. do we have a way to publish artifacts the way we do in build definition? Will “uploadFile” work in build definition also?

@MichelZ - Thanks for the details.

“Publish Test Results” task can be used within release and we support viewing the test results within the release environment from where the tests were executed.

Let us know if you face issues in doing this with newman based test execution.

Real shame. I think this would be a nice addition. E.g. we built the following pipeline:

• Build definition with Unit Tests, builds code
• Release definition deploying release to Azure
• newman Tests in release definition to run tests against the deployed Infrastructure

Would be nice to upload the tests back to the Artifacts.

We have improved the error message when artifact.upload command is used from any task when running within Release. This fix will be available in 2.114.0 onwards.

I also need the “publish artifacts” ability in release pipelines just like we have available in Build pipeline. Dont want to use that power-shell command to publish the artifacts because that is not the suitable way to publish in a pipeline.

Same need here, any news about it ?

@GitHubSriramB No, I am referring to tests of the API that are written using Postman (www.postman.com). newman is the “Command Line” execution part which can take a Postman collection and environment, and execute the written API tests.

There is a nice marketplace extension: https://marketplace.visualstudio.com/items?itemName=carlowahlstedt.NewmanPostman

Ideally, I would like to upload the test results (publish test results) so that they can be displayed somehow like this:

@bryanmacfarlane Yes, being able to publish from release is critical to upload error logs (e.g. WiX installation logs) to analyse deployment failures quicker and being able to fix production ASAP