octopusdeploy / octotfs Goto Github PK

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") {
    ...
}

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

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.

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?

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.

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.

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

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.

@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.

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!!!)

"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.

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.

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.

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

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.

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

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.

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.

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.

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

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

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 :-)

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

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?)

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.

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?

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)){

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

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.

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)

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).

there's a redirect url you should use:

http://aka.ms/tfbuild

Instead you used the url that it used to resolve to

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 ?

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?

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

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

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

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

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.

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?

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

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.

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?

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

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!

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 ?

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.

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.

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>