Azure-pipelines-tasks: PublishSymbols - From release manager

[Tasteful]

I want only to index and publish the indexed symbols when I'm doing a "public" release and not for all internal ci builds, when I moved the build task from the build into release management the publishing was stop working with error message ##[error]Required: 'Build.SourcesDirectory' task variable.

Should it work to publish the pdb-files from release management or what is the preferred flow to publish pdb-files when deploying to a specific environment in release management?

[bryanmacfarlane]

conditional tasks is rolling out this sprint. you can opt in to the preview feature.

you can condition the task on the reason it was queued - PR, CI, Release or any other variable that's set. We support full expressive conditions (like ARM).

[bryanmacfarlane]

closing since not a task issue. if you have any questions on conditionals, ask here.

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/conditions.md

[Tasteful]

@bryanmacfarlane so the error from task ##[error]Required: 'Build.SourcesDirectory' task variable. is not an task issue, do you mean that the error is in release management?

I'm using TFS2017.1 on-prem, possible to get a preview for that also?

[bryanmacfarlane]

Ahhh, I misunderstood. I thought you wanted to condition on being a CI/Release build definition. I see you're referring to RM.

[bryanmacfarlane]

Can you elaborate on your specific scenario? Typically, folks publish symbols after they build. And the build definition has full support for repos, triggers etc... Are you building on the RM side?

[Tasteful]

Build pipeline that is

1. Fetch source
2. Build all assemblies (combination of dotnet core and desktop versions)
3. Create nuget packages
4. Collect all pdb-files
5. Create artifact for nuget package
6. Create artifact for pdb files
7. Trigger the release manager flow

Release manager flow

Release manager have one definition that contains two different environments. Environment test and public with the steps below.

Automated triggered for environment test that is

1. Fetch artifacts from build
2. Publish nuget packages to internal nuget feed

After manually verifying that everything is working we manually trigger environment prod that is

1. Fetch artifacts from build
2. Index pdb symbol files and publish to symbol store (localy over smb share)
3. Publish nuget packages to public nuget feed

---

Before I changed to only publish pdb symbols to symbol store for release build the index pdb symbols and publish to symbol store was a part of the build pipeline but due to all builds it is eating up all disc with all the pdb´s that is for pull requests builds etc. Then I moved that into the release manager and the task is needing multiple environment variables that only exists for builds and will fail.

[ericsciple]

You need to index your sources during the build (pdb files are inspected, and source files need to exist during indexing).

However, I believe publishing phase doesn't need source files. So you may be able to run that part during the release.

[Tasteful]

Even that I run the symbol index part during build the publish part is throwing exception on https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/PublishSymbols/PublishSymbols.ps1#L31 and later https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/PublishSymbols/PublishSymbols.ps1#L35-L37 because of missing environment variables that starts with Build.

[Tasteful]

maybe use some parameters that can be changed depend on the environment, example

$definitionName = Get-VstsTaskVariable -Name 'Build.DefinitionName' -Require
$buildNumber = Get-VstsTaskVariable -Name 'Build.BuildNumber' -Require
$hostType = Get-VstsTaskVariable -Name 'System.Hosttype' -Require
if ($hostType -ieq "build") {
    $sourceDirectory = Get-VstsTaskVariable -Name 'Build.SourceDirectory' -Require
} elseif ($hostType -ieq "release") {
    $sourceDirectory = Get-VstsTaskVariable -Name 'System.ArtifactsDirectory' -Require
}

[ericsciple]

Ah, gotcha. As a workaround you can set those variables with the ##vso[task.setvariable command (see here)

[Tasteful]

after adding an inline powershellscript with the following content I got my flow to work, I also added to index the pdb in build flow and in release flow I checked skip index flag.

Write-Host "##vso[task.setvariable variable=Build_SourcesDirectory;]$env:SYSTEM_ARTIFACTSDIRECTORY"

this hack was a nice one, was trying to set them on the variable tab but didn't get any dynamic values in them and the pipeline was broken.

@ericsciple thanks for the fast help to find a workaround for the problem.

[ericsciple]

@sprendermsft - fyi

@Tasteful Great, I'm glad that worked for you. Technically the task isn't supported within a release today (not that it won't work, but a patch update might accidentally break it because it's generally not considered when making changes to the task). I'm reassigning the issue to @sprendermsft so his team can assess whether they want to properly add support for the scenario.

[Tasteful]

Updated workflow with the index/publish symbols step in correct location.

Build pipeline

1. Fetch source
2. Build all assemblies (combination of dotnet core and desktop versions)
3. Create nuget packages
4. Collect all pdb-files
5. Index symbol files (not publish)
6. Create artifact for nuget package
7. Create artifact for pdb files
8. Trigger the release manager flow

Release manager flow

Release manager have one definition that contains two different environments. Environment test and public with the steps below.

Environment test

Automatic triggered from build

1. Fetch artifacts from build
2. Publish nuget packages to internal nuget feed

Environment public

Manually triggered after manual verification of packages in test environment

1. Fetch artifacts from build
2. Temporary steps that set $env:Build_SourceDirectory (see https://github.com/Microsoft/vsts-tasks/issues/3897#issuecomment-290524004)
3. Publish symbol store (localy over smb share) without indexing
4. Publish nuget packages to public nuget feed

[bryanmacfarlane]

Good to close?

[ericsciple]

yes i fwd'd along to sean, i'll fwd to dan dan too

[liben-y]

I've had this issue as well. I was trying to index sources and publish symbols from release manager. I put in the powershell work around which got me to another error:

[error]Associating server artifact is not supported in Release.

The reason I'm using release manager for this task is similar to what @Tasteful was doing, package management of different versions, but unlike him, I'm trying to run a dotnet pack in order to create the nuget artifacts so that I can control the version created for each environment. So for -alpha version I have an "alpha" environment which tags -alpha at the end of the build number I'm generating for the assembly version. Similar for beta, rc, rtm I use the environment variables to tag onto the build version, with rtm not tagging anything so that it is seen as a the final release.

I've seen what is currently available with vsts release views and because the view names are not tagged onto the actual version it forces you to create multi-view sources in visual studio in order to consume.

I know this breaks the principle that the build should provide the "build" artifacts, but I think its the least friction way to achieve a proper nuget version pipeline. Also I'm setting the assembly version with the tagged version in the csproj file too.

Is there scope for this task to support being run from release manager?

[danebou]

@ericsciple Is this fixed in a future release? We're still having this problem and it looks like the workaround broke. Maybe reopen?

[error]Unable to process command '##vso[artifact.associate artifacttype=SymbolRequest;artifactname=libraries/...]...' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)

[error]Associating server artifact is not supported in Release.

[alohaninja]

@danebou - this issue still exists for us also - not sure why we're being forced to do this in build-only pipelines and not releases.

Error publishing during Release

Unable to process command '##vso[artifact.associate artifacttype=SymbolRequest;artifactname=...
Associating server artifact is not supported in Release.

Evidently there is a breaking change for artifact logging commands. We are using the Continue on Error for now for a partial success.

If it's not a supported task, why is it listed as a task that can be added to a Release definition? Please make this configurable - seems like the symbols are still publishing regardless of this error.