VSTS Create Release returns 401 Unauthorized for a Channel

[mike_jarosch]

We are seeing the Azure DevOps Create Release step returning 401 Unauthorized for a single channel in a project. Things like pushing packages, creating a release for a different channel in the project and creating released in other projects (they only have a single channel) all are working correctly. They all share the same service reference with the same API key.

We have been using this forever without any issues. It worked last week and nothing has changed between now and then that we are aware of.

Any ideas?

[mike_jarosch]

Here is some more information related to the problem:

We are running the step on a hosted agent on a VM in Azure. Looking at the source for the step, it appears to be failing when it attempts to get the Work Items associated with the build from VSTS.

Create step logs:
2018-12-19T14:35:29.5791716Z ##[section]Starting: Create Octopus Release
2018-12-19T14:35:29.5948154Z ==============================================================================
2018-12-19T14:35:29.5948154Z Task : Create Octopus Release
2018-12-19T14:35:29.5948154Z Description : Create a Release in Octopus Deploy
2018-12-19T14:35:29.5948154Z Version : 2.0.135
2018-12-19T14:35:29.5948154Z Author : Octopus Deploy
2018-12-19T14:35:29.5948154Z Help : Version: 2.0.135. More Information
2018-12-19T14:35:29.5948154Z ==============================================================================
2018-12-19T14:35:30.7198189Z Environment = Bitbucket
2018-12-19T14:35:30.7198189Z Comments = True, WorkItems = True
2018-12-19T14:35:31.3603727Z ##[error]The remote server returned an error: (401) Unauthorized.
2018-12-19T14:35:31.3760188Z ##[section]Finishing: Create Octopus Release

[Matthew_Casperson]

Hi @mike_jarosch, thanks for reaching out.

You may be able to resolve this issue by upgrading to version 3 of the TFS plugin. You can use the new version of the plugin by selecting it from the Version drop down box.

Regards
Matt C

[mike_jarosch]

Hi Matt,

I have tracked down the issue to the fact that we use an external git repo (bitbucket) and VSTS is returning truncated change messages, and I think the plugin is expecting to talk to VSTS not an external repo for the full message.

I upgraded to version 3 and I’m getting the following error message. We are running our own server for agents, so I am guessing I am missing a requirement, but I don’t know what.

2018-12-27T19:43:46.8856333Z [command]C:\Windows\system32\cmd.exe /D /S /C "F:\vstsagents\agent1\_work\_tool\Octo\4.45.0\x64\Octo.cmd create-release "--project=********" "--releaseNumber=2018.12.27.1" "--server=********" "--apiKey=********" --enableServiceMessages "--releaseNotesFile=F:\vstsagents\agent1\_work\r2\a\release-notes-b9c2cf50-0a0f-11e9-b5cd-75b905f2c632.md""

2018-12-27T19:43:47.1042821Z

2018-12-27T19:43:47.1042821Z F:\vstsagents\agent1\_work\r2\a>dotnet "F:\vstsagents\agent1\_work\_tool\Octo\4.45.0\x64\/Octo.dll" create-release "--project=********" "--releaseNumber=2018.12.27.1" "--server=********" "--apiKey=********" --enableServiceMessages "--releaseNotesFile=F:\vstsagents\agent1\_work\r2\a\release-notes-b9c2cf50-0a0f-11e9-b5cd-75b905f2c632.md"

2018-12-27T19:43:47.1511881Z Error initializing the dependency resolver: A fatal error was encountered, missing dependencies manifest at: F:\vstsagents\agent1\bin\Microsoft.NETCore.App.deps.json

2018-12-27T19:43:47.1511881Z

2018-12-27T19:43:47.1667761Z ##[error]Error: F:\vstsagents\agent1\_work\_tool\Octo\4.45.0\x64\Octo.cmd failed with return code: 2147516555

2018-12-27T19:43:47.1667761Z ##[error]Failed to deploy release F:\vstsagents\agent1\_work\_tool\Octo\4.45.0\x64\Octo.cmd failed with return code: 2147516555

2018-12-27T19:43:47.1824251Z ##[section]Finishing: Create Octopus Release: XXXXXX

[mike_jarosch]

Figured out that we needed .NET Core 2.0 or greater to be installed on the server. Installing that fixed the 3.0 issue and we are back to creating releases.

Does anyone know how to get .NET Core to show up as a capability for the agent?

[Matthew_Casperson]

Hi @mike_jarosch

You can add the .NET Core SDK Installer step to ensure the build agents have the appropriate .NET Core runtime available. This step will download and place the DotNET Core SDK or runtime on the path if it is not already available.

Regards
Matt C