octopusdeploy / octotfs

| Public | Octopus extensions for Azure DevOps, TFS, VSTS, and VSO

OctoTFS

OctoTFS is a set of packaging and release tasks and a widget for using Octopus Deploy with Azure DevOps and Team Foundation Server (TFS).

Azure DevOps was formerly known as Visual Studio Team Services (VSTS) and Visual Studio Online (VSO).

OctoTFS is made up of several tasks to make it easy to integrate TFS and ADO with Octopus Deploy. This is packaged up as a web extension that can be installed in TFS or ADO.

TFS / Azure DevOps Web Extension Custom Tasks

To learn more about how to use the extension and custom tasks, read the VSTS README.

• Push Package(s) to Octopus
• Push Package Build Information to Octopus
• Create Octopus Release
• Deploy Octopus Release
• Promote Octopus Release

This extension provides a friendly interface to the Octopus CLI which does the heavy lifting to integrate.

Dev

Microsoft TFS/ADO web extensions are powered by Node.js under the hood. Simply open the repo with your favourite text editor like Jetbrains WebStorm or Visual Studio Code and you're good to go.

Building

Prerequisites

• Node.js 10.15.3 (LTS) (choco install nodejs or brew install node@10 or web)
• NPM: 5.6.0+ (npm install npm@latest -g)
• TFX (npm install tfx-cli -g)
• Install golang (choco install golang or brew install go or web)
• Node-Prune (go get github.com/tj/node-prune)
• PowerShell (choco install powershell-core or brew cask install powershell or web (google it...))

NOTE: PowerShell is required if you intend to publish the extension either to a local TFS instance or otherwise.

How to build and package the extension

Microsoft's web extension tooling is cross platform so you can run this on Windows or macOS.

Build

Run the following at a commandline.

• npm install --no-save
• npm run build

This will generate the full extension content required to create the extension VSIX.

Packaging

In order to package and test the extension on a local TFS instance, without publishing to the marketplace, you can run the following at a PowerShell command prompt.

./pack.ps1 -environment localtest -version "x.x.x"

Releasing

To create a new release:

• Merge your changes PR to main
• Check the PACKAGE_VERSION variable value in the build.yml. Bump the major/minor as appropriate for the changes being released (this will require another branch/PR because of RBAC). ⚠️ DO NOT bump these numbers prior to the release going out, branch builds can impact each other if they do this because the marketplace enforces forward only on version numbers and it is imperative that all currently active branches use the same major.minor values.
• Work out what the next run number in GitHub is going to be. Create a release and tag with the version based on PACKAGE_VERSION and the run number, remembering to prefix the release with a v. The pipeline will automate things from once the GitHub release is created.

How to test the extension

If you're doing updates, enhancements, or bug fixes, the fastest development flow is to code locally, build, package and deploy locally. Once your changes are stable, it's a good idea to deploy to Test for further testing, and finally Production.

Local

It's highly recommended to set up two Virtual Machines running Windows Server. This is generally done locally, and it's best to give your VM at least 8 gigs of memory and 4 CPU cores, otherwise the TFS/ADO installation can fail or take hours.

1. Microsoft TFS Server 2017 Update 1 - This is the first version of TFS that supported extensions, so it's very good for regression testing.
2. Microsoft Azure DevOps Server vLatest - This is the on-prem version of Microsoft's hosted Azure DevOps services/tooling. It's generally faster/easier to test this locally than continually publishing to the Azure DevOps Marketplace.

To install locally, build and package the application as per the instructions above. Then install the extension by uploading it. Instructions to do this are available in Microsoft's TFS/ADO docs.

Additional tips

• TFS/ADO is accessible on port 8080 by default (this can be changed if desired) at something like the following: http://<server name/ip>:8080/tfs/
• The TFS/ADO "Manage Extensions" page, where you upload test extensions, is available at http://<server name/ip>:8080/tfs/_gallery/manage
• You may need to tweak your VM firewall settings to access it from outside of your VM in the host OS. Assuming it's local, turning it off is pretty quick and safe.

Testing Gotchas

• If you design a build pipeline with the current live extension, you can't upgrade it to a local version. You need to install the localtest extension first and use it in your builds. Then you can upgrade it and you will get your latest changes.
• We need to maintain backwards compatibility, and we need to ensure any existing builds will not break after we publish an update. Therefore regression testing is critical. The recommended approach for regression testing is to build the current live extension for localtest and create build pipelines covering the areas you're changing. Then update the extension and re-run all your builds to ensure everything is still green/working.
• Building on the previous point, there is no way to roll back an extension so testing is difficult as well. The recommended approach to this is to snapshot your local test VMs when you have a working build, so you can update the extension and revert back to the snapshot as needed.
• During manual testing against our test environment on Azure DevOps, the devops@... account has access for publishing to test and production environments (if you try to do this from your personal account, publishing will fail). When you create your security tokens, do this from the devops account and either setup an expiry and/or remove the token when you are finished with it.
• At the time of writing, we have a build pipeline on ADO, which builds and pushes packages to our deployhq project, where we can then release to Test and Production.
• If the deployHQ task fails due to a timeout (which is common), trying again on the octopusHQ task will not fix it. You need to squirrel into the VSTS task (see the task log in octopusHQ, it will have a link to the VSTS task in the log, which will have a link to the Web, click that and it'll take you to the problem), see that it's failing on all the steps related to v4 of our octo tool, run the same task again (as new) (don't re-run the existing task that's failed), wait for that to succeed, then re-run our task in deployHQ and it will then succeed. We want to allocate time to investigate why this is so awkward, but for now, we're documenting here for discoverability.

Test environment

Octopus staff can publish an extension for testing which is wired up to a test Azure DevOps organization. This is a great area for further live testing against the latest and greatest release of Azure DevOps.

• Octopus Extension in Marketplace
• Octopus VSTS Environment
• Security Tokens

NOTE: See the OctopusHQ Confluence for further details on gaining access to the Azure DevOps (aka VSTS) test environment.

Production environment

Octopus staff can publish an extension for production use.

• Octopus Extension in Marketplace
• Octopus VSTS Environment
• Security Tokens

NOTE: See the OctopusHQ Confluence for further details on gaining access to the Azure DevOps (aka VSTS) production/live environment.

Other Useful Links

• Marketplace Publishing Portal (octopusdeploy)

octotfs's Issues

Octopus Promote-Release

Task for promoting a release from one Environment to another Environment: http://docs.octopusdeploy.com/display/OD/Promoting+releases

The link to Create Octopus Release in the Readme.md does not work

There is a link to Create Octopus Release in the PowerShell scripts section of readme.md that points to a location that does not exist:

<a href="/OctopusDeploy/OctoTFS/blob/master/source/BuildPowershellScripts/CreateOctopusRelease.ps1">Create Octopus Release</a>

Not deploying the build just produced...

It appears that this task will always deploy the highest revision in the repository...This is fatal with concurrent development. Let consider 1.1.x.x and 1.2.y.y are both being developed. A new build of 1.1 creates a deploy that uses the highest published (Which will be 1.2!!!)

Not always expanding variables in Octopus Package Step

I have no idea why this is happening but spent a couple of hours trying to figure it out...

I have two projects, both with identical Create Package Steps that look like this

In one build this works fine, in another it fails and I had to use an environment variable instead like this

The build themselves are different, the once which works is using MSBUILD, the second is using command line to build a dotnet core app.

I put a command line with a SET just before the Octopus Step and the environment variable are all there so for some reason in the failing build the environment variable isn't expanding.

I'm working for now but I thought I'd put this here in case someone else know the reason or comes here looking for answers :-)

Not selecting the correct version for channel

Hi there,
I have a CI and ReleaseCandidate build that push the same package up to Octopus with the only difference being one is tagged -CI, the other -RC.
Prerelease info is date+buildrev

My CI build pushed this package up "11.0.0-meta2016021506-CI"
My RC build pushed 11.0.0-meta2016021503-RC

I am passing the channel and version as an additional arguement. Yet the task fails with:
"The requested package versions for the following steps violate the channel version rules: Deploy Octo.Test.Feature. Please specify a different package version, channel or provide the ignoreChannelRules parameter to override this check."

If I try to manually create the release in Octopus, it selects the correct package and creates the release as expected. So it appears to me that everything is setup correctly.

Everything looks ok in the build logs, up until the point it selects the version for the release, am I doing something incorrectly or is there a bug?:

2016-02-14T20:41:10.9943917Z Path to Octo.exe = E:\Installs\agent\tasks\OctopusCreateRelease\0.3.0\Octo.exe

2016-02-14T20:41:10.9943917Z E:\Installs\agent\tasks\OctopusCreateRelease\0.3.0\Octo.exe create-release --project="Octo.Test.Feature" --server=myServer --apiKey=myapikey --releaseNotesFile="E:_work\e29783df\a\release-notes-e6ccfbec-e802-4e16-9ccb-f36c4577b933.md" --channel=ReleaseCandidate --version=11.0.0-meta2016021503-RC

2016-02-14T20:41:11.1193825Z Octopus Deploy Command Line Tool, version 3.2.0.91

2016-02-14T20:41:11.3068966Z Handshaking with Octopus server: "OurOctopusServer"

2016-02-14T20:41:11.5569017Z Handshake successful. Octopus version: 3.2.6; API version: 3.0.0

2016-02-14T20:41:11.6194018Z Authenticated as: OurServiceAccount<> (a service account)

Finding project: Octo.Test.Feature

2016-02-14T20:41:15.3851322Z Finding channel

2016-02-14T20:41:15.4476323Z Finding deployment process for project: Octo.Test.Feature

2016-02-14T20:41:15.5101313Z Finding release template...

2016-02-14T20:41:15.6195228Z Resolving NuGet package versions...

2016-02-14T20:41:15.6195228Z Finding latest NuGet package for step: Deploy Octo.Test.Feature

2016-02-14T20:41:15.8226548Z Using version number provided on command-line.

2016-02-14T20:41:15.8226548Z Release plan for release: 11.0.0-meta2016021503-RC

2016-02-14T20:41:15.8226548Z Steps:

2016-02-14T20:41:15.8226548Z # Name Version Source

2016-02-14T20:41:15.8382667Z --- ---------------------------- --------------- ------------------------------------

2016-02-14T20:41:15.8382667Z 1 Deploy Octo.Test.Feature 11.0.0-meta2016021506-CI Latest available in NuGet repository

2016-02-14T20:41:15.8382667Z Creating release...

2016-02-14T20:41:16.5882854Z Error from Octopus server (HTTP 400): There was a problem with your request.

2016-02-14T20:41:16.5882854Z - The requested package versions for the following steps violate the channel version rules: Deploy Octo.Test.Feature. Please specify a different package version, channel or provide the ignoreChannelRules parameter to override this check.

2016-02-14T20:41:16.5882854Z Exit code: -7

2016-02-14T20:41:16.6039128Z ##[error]Unexpected exit code -7 returned from tool Octo.exe

Installing on-premise TFS

Hi,

When I run the pack.ps1 script it generates the vsix file but then get an error when uploading via tfs saying the manifest is an invalid file format.

Have you got steps/example/screenshots of how to install this extension for on premise TFS please?

Can I use this now with VSOnline ?

I'm really excited by the work being done here with vNext Build Preview. I'm not sure what the blog post meant about having to wait until RTM ?

What stops me from using this goodness now ?

Is there anyway to get going with this now ?

Push Packages - multiline support not working?

@MJRichardson

I'm receiving the following error when trying to use the multi line support feature in the Push Task Extension. Are the newlines being interpreted as command executes? Thanks in advance.

2016-07-29T00:14:44.0952344Z ##[error]Cannot validate argument on parameter 'Arguments'. The argument "push --package="E:_work\24\a\package1.nupkg
2016-07-29T00:14:44.0952344Z ##[error]E:_work\24\a\package2.nupkg
2016-07-29T00:14:44.0962331Z ##[error]E:_work\24\a\package3.nupkg
2016-07-29T00:14:44.0962331Z ##[error]E:work\24\a\package4.nupkg
2016-07-29T00:14:44.0972304Z ##[error]E:work\24\a\package5.nupkg" --server=http://***deploy/ --apiKey=*** " does not match the "^[^\r\n]$" pattern. Supply an argument that matches "^[^\r\n]$" and try the command again.

Not Processing Variables in Octopus Arguments...

I would like to pass: --packageversion=0.0.$(DayOfYear)$(Rev:.rr)

However, this appears to be passed the command-line as a literal without substituting the appropriate elements (to create a 4 part version number).

(401) Unauthorized when trying to create release in on-premise TFS 2015

We recently upgraded our Octopus extension from 0.6.14 to 1.0.1 and we have run into trouble creating a release when "Include Changeset Comments" is turned on. Looking over the code I'm guessing that the changes API request is failing:
Environment = TfsVersionControl
Comments = True, WorkItems = False

[error]The remote server returned an error: (401) Unauthorized.

This is how the task is set up:

We're running TFS 2015 Update 2

If you need any more information let me know.

No release notes for Powershell option

Task fails when running in Release in VSTS (ex-VSO)

I'm executing Create Octopus Release step in Release mode in Visual Studio Team Services. But I get an error saying Cannot bind argument to parameter 'Path' because it is null.

I run the same step as a Build step and everything works fine. Sound like the same issue as #29, but I'm unsure if error is the same. Here is my log:
vso_createRelease.txt

Also the problem looks the same as I had with executing Publish NuGet script in Release (http://stackoverflow.com/q/34790751/809357) and the solution for that problem was like this: https://github.com/Microsoft/vso-agent-tasks/pull/1034/files

Build.vNext link goes to 404

there's a redirect url you should use:

http://aka.ms/tfbuild

Instead you used the url that it used to resolve to

VSTS buildUri is incorrect when creating release notes

$projectName/_BuildvNext#_a=summary&buildId=$buildId should be $projectName/_build/index?_a=summary&buildId=$buildId

Release notes URL not encoded

If you have a VSTS project whose name includes spaces, and you included release notes as part of the Create Octopus Deploy VSTS build step, then the release notes will contain an invalid URL and the markdown cannot be rendered correctly as markdown.

For example, if your project name is A Project With Spaces and you have a build like this:

then you will end up with a release like this:

Notice the release notes: Release created by Build [A Project With Spaces-CI #89](https://octopus-deploy-test.visualstudio.com/A Project With Spaces/build/index?a=summary&buildId=89) from the A Project With Spaces repository in Team Project A Project With Spaces.

The link is not rendered correctly as a markdown link because the URL contains space characters from the project name. The raw markdown should instead be Release created by Build [A Project With Spaces-CI #89](https://octopus-deploy-test.visualstudio.com/A%20Project%20With%20Spaces/build/index?a=summary&buildId=89) from the A Project With Spaces repository in Team Project A Project With Spaces. That is, the project name should be a correctly encoded URL. If this were the case, then the URL would be rendered correctly as a link.

The release notes here are being supplied as markdown by the Octopus VSTS plugin, so this plugin should be responsible for supplying valid URLs.

Push packages - support pattern/minimatch for nupkg file(s)

Push packages only supports an exact path to the nupkg file (or files).
Support for pattern/minimatch would be very usefull because then you don't need to specify every nupkg file, with the correct path, and the correct version number.

I would use this:
$(build.sourcesdirectory)\**\octopacked\*.nupkg

Looks like the VSO Tasks lib already has something for this included.
https://github.com/Microsoft/vsts-task-lib/blob/master/powershell/VstsTaskSdk/FindFunctions.ps1

Package application task includes everything

When using the package application task it includes everything in the directory, would be nice if it was more like octopack and included just what was needed (maybe allow Source Path to be a csproj file instead of a folder?)

Filter Changeset Comments

In one VSTS collection we have multiple solutions, each with multiple branches. I have configured a CI build definition that is triggered on one of these branches and using a combination of octopack and the "Create Octopus Release" build step to automate the deployment process.

This is all working excellently and being able to include Changeset comments is awesome so we have visibility into what is included in the release. However, I have now noticed that the option to include all changeset comments does so for the whole collection (since last build) - not just the branch this release is triggered from.

Is it possible to have the ability to filter the release notes? Either as a configurable value in the build step, based on the repository mapping or some other configuration in the build definition?

API key in the logs

Hi guys,

VSTS does a great job with hiding credentials with service configuration. The logs from the powershell display these api keys in clear text however.

Don't push packages for `refs/pull/*/merge` branches

Since there are no conditional build tasks in VSTS yet, it would be great to have a check in the Octopus-Push task that will effectively noop if it detects that it is being executed on a build from a refs/pull/*/merge branch. This will allow people to reuse a single build definition for CI builds and have their pull request branch policy for master (or whatever) set to use this same CI build def.

Octopus Deploy-Release

Task for deploying releases: http://docs.octopusdeploy.com/display/OD/Deploying+releases

Octopus-Push.ps1 only pushes first file

I am using $(Build.SourcesDirectory)\**\bin\**\*.nupkg to identify the packages to upload. I'm expecting the following packages to be matched to this filespec:

• Product.Database\bin\release\Product.Database.X.Y.Z.nupkg
• Product.Portal\bin\release\Product.Portal.X.Y.Z.nupkg
• Product.Portal.Offline\bin\release\Product.Portal.Offline.X.Y.Z.nupkg

Version 2 of the Octopus push build step only finds and pushes the first package. I've tried to re-produce this locally and I don't get any files resolved. Regardless, I think the issue is that Get-Item is used instead of Get-ChildItem. Get-Item only looks at a specified location and doesn't handle recursion. See https://github.com/OctopusDeploy/OctoTFS/blob/master/source/VSTSExtensions/OctopusBuildAndReleaseTasks/Tasks/Push/Octopus-Push.ps1#L27

This line should be changed to

foreach ($file in (Get-ChildItem -Path $Package -Recurse)){

Dashboard widget not compatible with TFS if using a different Collection

See questions in https://marketplace.visualstudio.com/items?itemName=octopusdeploy.octopus-deploy-build-release-tasks#qna for more detail.

The code in octo-status.js appends defaultcollection to the server URL. Instead, there should be a field where the collection can be set, or (if possible), the current collection read identified and specified.

Error with custom build step

I received this error while attempting to run the custom build step on TFS:

2015-08-25T17:42:24.4172512Z Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: <. Path '', line 0, position 0.
2015-08-25T17:42:24.4172512Z    at Newtonsoft.Json.JsonTextReader.ParseValue()
2015-08-25T17:42:24.4182512Z    at Newtonsoft.Json.JsonTextReader.ReadInternal()
2015-08-25T17:42:24.4182512Z    at Newtonsoft.Json.JsonTextReader.Read()
2015-08-25T17:42:24.4192512Z    at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadForType(JsonReader reader, JsonContract contract, Boolean hasConverter)
2015-08-25T17:42:24.4192512Z    at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
2015-08-25T17:42:24.4192512Z    at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
2015-08-25T17:42:24.4202512Z    at Newtonsoft.Json.JsonConvert.DeserializeObject(String value, Type type, JsonSerializerSettings settings)
2015-08-25T17:42:24.4202512Z    at Newtonsoft.Json.JsonConvert.DeserializeObject[T](String value, JsonSerializerSettings settings)
2015-08-25T17:42:24.4212512Z    at Octopus.Client.OctopusClient.DispatchRequest[TResponseResource](OctopusRequest request, Boolean readResponse)
2015-08-25T17:42:24.4212512Z    at Octopus.Client.OctopusClient.Get[TResource](String path, Object pathParameters)
2015-08-25T17:42:24.4222512Z    at Octopus.Client.OctopusClient.EstablishSession()
2015-08-25T17:42:24.4222512Z    at System.Lazy`1.CreateValue()
2015-08-25T17:42:24.4232512Z    at System.Lazy`1.LazyInitValue()
2015-08-25T17:42:24.4232512Z    at System.Lazy`1.get_Value()
2015-08-25T17:42:24.4242512Z    at Octopus.Client.OctopusClient.get_RootDocument()
2015-08-25T17:42:24.4242512Z    at OctopusTools.Commands.ApiCommand.Execute(String[] commandLineArguments)
2015-08-25T17:42:24.4252512Z    at OctopusTools.Program.Main(String[] args)
2015-08-25T17:42:24.4252512Z Exit code: -3
2015-08-25T17:42:24.4342512Z ##[error]Unexpected exit code -3 returned from tool Octo.exe

I can provide more details on request.

Fix release notes gathering for Create Release task in RM

If you use the Create Octopus Release task in the context of Release Management rather than Build, and you have the Changeset Comments and Work Items checkboxes checked, the step will fail.

The task uses the Build.BuildID environment variable to query the build. In RM, this variable has a different name related to the artifact. We should handle this.

See http://help.octopusdeploy.com/discussions/problems/49005 for details.

Selecting correct packages

When using the TFS custom build step it doesn't select packages according to the channel rules.

If the Tag rule is 'Dev.*' it should only select packages that fit this rule when creating the release.

Is there any way to make it obey these rules?

Create Release task grabs highest package version, not one just made

Would be nice if there was an easy way to create a release for the package we just made with the package application task, even if it has a lower version number than what the latest is in octopus.

Error in latest version (2bbaa1c)

Hi,

I uploaded the latest version (2bbaa1c) to our TFS 2015 install today and we're getting the following error when trying to create an Octopus release:

2015-11-30T09:33:13.0721149Z ##[error]At C:\TFS Build Agent\tasks\OctopusCreateRelease\0.4.0\Octopus-CreateRelease.ps1:55 char:1
2015-11-30T09:33:13.0721149Z ##[error]+ - $relatedWorkItems = $relatedWiResponse.Content | ConvertFrom-Json
2015-11-30T09:33:13.0721149Z ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
2015-11-30T09:33:13.0721149Z ##[error]The assignment expression is not valid. The input to an assignment operator must be an object that is able to accept assignments, such as a variable or a property.
2015-11-30T09:33:13.0721149Z ##[error]At C:\TFS Build Agent\tasks\OctopusCreateRelease\0.4.0\Octopus-CreateRelease.ps1:62 char:1
2015-11-30T09:33:13.0721149Z ##[error]+ - $workItemsDetails = $relatedWiDetailsResponse.Content | ConvertFrom-Json
2015-11-30T09:33:13.0721149Z ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2015-11-30T09:33:13.0721149Z ##[error]The assignment expression is not valid. The input to an assignment operator must be an object that is able to accept assignments, such as a variable or a property.

On this specific build definition we have the following Octopus properties defined:
The Deploy Release To: Dev
Additional Octo.exe Arguments: --progress --version $(Build.BuildNumber)-$(Build.DefinitionName)

Use assembly version

At the moment I'm using OctoPack together with a Create Release step.
I'd like to replace OctoPack with the new Pack and Push tasks, but one thing I'm missing is using the assembly version in the package name like OctoPack does.

Is this something you plan on adding to the tasks?

TFS vNext Build Fails with Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available

Invoke-WebRequest : The response content cannot be parsed because the Internet Explorer engine is not available, or

Internet Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again.

I've tried adding the -UseBasicParsing into the script too but I then get a bunch of different errors. But this might be related to the other Issue I've logged.

Octopus Connection type

At the moment we use a GenericConnection where you need to ignore the Username field, and we use Password as API key.

We should make an OctopusConnection contribution as part of our Extension.

Octopus-CreateRelease.ps1 fails because environment variable does not exist

Script uses $env:BUILD_STAGINGDIRECTORY instead of $env:SYSTEM_ARTIFACTSDIRECTORY.

https://github.com/OctopusDeploy/OctoTFS/blob/master/source/VSTSExtensions/OctopusBuildTasks/CreateOctopusRelease/Octopus-CreateRelease.ps1#L136

Source: http://help.octopusdeploy.com/discussions/problems/43509

Task.json needs powershell demand

Each of the tasks need to demand powershell. This is imporntant for agent pools that have a mix between MS build agents and cross platform build agents.

Example here:
https://github.com/Microsoft/vsts-tasks/blob/master/Tasks/Npm/task.json#L14

Bug in Get-SelectedPackages

There seem to be a bug in the above mentioned function.

The "return $packageVersions" line is located inside the for-each which creates invalid return data.

Moving the return statement outside the for-each fixed the script for our usecase where we have a seperate nuget server and thus not using the built-in one.

Add support for pushing a nupkg to OD as a discrete build step

I use the project configuration in OD to create the release. What I'm after is the ability to publish the package to OD after tests have passed. For example:

Run msbuild
Run tests
Publish package

Currently the only option appears to be to publish as part of OctoPack in MsBuild. The downside of this is that it publishes the packages for deployment even if the tests indicate a busted build.

RTM is here

Is there a way to hack this into the on-premises TFS that was released today? It seems like custom tasks still aren't fully supported, but it would be nice to test this out now.

Extract artifacts from created release

I would like to pull back artifacts that my release/deployment creates. Ideally, the artifacts could be filtered (wildcard or file name matching).

I have an MS Test project that is running as part of my deployment. This generates a .xml and .trx file, both of which I would like to pass to the vNext built-in task to Publish Test Results.

Publish packages does not append packages arguments

Hello,
I have the following scenario on TFS 2017:
in my publish package i have set package to be : $(Build.ArtifactStagingDirectory)\My.Package.Name.$(Build.BuildNumber).nupkg
the file exists on disk and is on the proper location ex: C:\Agent1\_work\2\a\My.Package.Name.2017.2.28.19.nupkg
and the error i get is :

"C:\Users\build\Desktop\Agent\tasks\OctopusPush\2.0.44\Octo.exe" push --server=http://redacted/ --apiKey=********
Octopus Deploy Command Line Tool, version 4.5.0
Handshaking with Octopus server: http://redacted/
Handshake successful. Octopus version: 3.7.10; API version: 3.0.0
Authenticated as: redacted <*redacted@*redacted> 
Please specify a package to push
Exit code: -1

And i can't make it work for the life of me... Any help is much appreciated

Task log is not presented in TFS build console

Hi,

We use OctoTFS to create and deploy the packages which is created by msbuild. When the deployment is started, the build console in TFS only shows:

2016-06-06T12:15:57.8201301Z GET http://our.url/api/tasks/ServerTasks-11927
2016-06-06T12:15:57.8670232Z GET http://our-url/api/tasks/ServerTasks-11927/details

in the end and keeps repeating.

When I use octo.exe and trigger the deploy manually I get a lot of logging stuff like in the powershell window:

Success: Acquire packages
Info Acquiring packages
Info Making a list of packages to download
Info Downloading package My.Package version 1.0.9-Develop058 from feed: http://our.nuget.url/OctopusNugetServer/nuget'
Info All packages have been acquired

and much more.

We have tried using --progress and --debug, but no luck in TFS.

Is this a bug or just something we have not activated?

CORS error loading octopus in new tab

Source: https://secure.helpscout.net/conversation/361239768?folderId=969747

The widget allows you to click through to the specific deployment shown. It uses target="blank" to open in a new window.

Unfortunately, this triggers CORS protection, as origin is null when target="_blank" is used.

See https://webmasters.stackexchange.com/questions/85793/xsrf-error-when-link-is-opened-via-an-a-tag-with-target-attribute-set-to-bla.

Related to OctopusDeploy/Issues#3491

Build Repository Provider constant is different

Hey, I just started using this and it's AWESOME! I'm using VSO with the new build system. I had to make one minor change to get the changeset comments and work items included in the build release notes. The code is currently looking for the repo provider to be named "Tfvc" but after not getting these comments I did some debugging and found that my repo provider is named "TfsVersionControl". I'm not sure why this is different but I changed the two checks to look for this constant and everything worked after that:

if ($env:BUILD_REPOSITORY_PROVIDER -eq "TfsVersionControl") {
    ...
}

User/Pass option for Custom Build Task doesn't work

Octo.exe doesn't currently support user/pass authentication. You need an API key.

Minimum agent version Invalid

"minimumAgentVersion": "1.82.0" is wrong.

This version is provided with TFS 2015 (On premise, first version, not update 1). And this agent doesn't support some environment variables and log tools used in TfsServiceMessage (see Octo.exe).

On upload, the task will break build system.

How do I find out the Project Id

The CreateOctopusRelease.ps1 script asks for -octopusProjectID.

I've realised this is not something I can see from the Project screen in Octopus, how do I find out what the id is for any given project ?

Not handing the progress flag to octo.exe correctly

In DeployRelease we set the progress flag as --progress=true/false but octo.exe just treats any provision of --progress as being true.

VSTS dashboard widget showing wrong release

Using Octopus server 3.3.11

Here is a screenshot of the project and environment from Octopus

...and here's what it looks like in the widget

Not setting $AdditionalArguements in Octopus-DeployRelease.ps1

In the Deploy Release script $AdditionalArguments is not set before it is appended to the call to octo.exe.

See Octopus-CreateRelease.ps1 for example.

Output a link to the new Ocotpus build to the build summary page in VSTS

Great extension - just added to VSTS project, and it works like a charm.

With the old XAML based TFS build system, I had made my own extensions to the build template to create an Octopus release with the Octo.exe tool, which I guess is exactly the same as you do here. What I also did then was to add a custom element to the "build summary" output for the TFS build with a link to the newly created release on Octopus. This means that our developers can simply wait for the build to finish and then jump straight to the Octopus release from the build summary to e.g. trigger a release to the dev environment.

I'm pretty new to the new TFS Build system, but as far as I understand, you can do something similar by simply outputting a special string to the standard output starting with "##vso" - see details here: https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md

It seems that you can output a bit of markdown and that this will then be rendered on the build summary page in TFS. So the link could added that way.

This would be a great feature in the extension!

Validate Octopus URL for common mistakes

We often get tickets from users that get 404s in their Octo.exe calls because they registered they URL like http://Octopus/app#/ or http://octopus/api/ instead of using the base URL http://Octopus. This is a very common and understandable mistake and unfortunately the dialog box where you register the connection endpoint in TFS/VSTS doesn't allow us validate the user input before they save it.

So as a workaround, we could validate the URL in our build scripts.

Octopus Push-Packages

Task for pushing packages: http://docs.octopusdeploy.com/display/OD/Pushing+packages