OCTO.EXE is raising an error when called from the TFS Release Task relating to API key it not being set

I have imported the Octopus Release Task to the our on-prem TFS2015. I have set the end point using the URL, dummy username and API key for the password. I added the Release Task as a build step however the task fails when running OCTO.EXE

D:\tfs\tasks\OctopusCreateRelease\0.4.5\Octo.exe create-release --project=“myProject” --server=xxxxxxx–user=N/A --pass= --releaseNotesFile="D:\tfs\agent_work\9\a\release-notes-41000d57-316d-42f4-bd29-9032470711be.md"
2016-01-13T21:18:36.2684274Z Octopus Deploy Command Line Tool, version
2016-01-13T21:18:36.4871816Z Please specify your API key using --apiKey=ABCDEF123456789. Learn more at: https://github.com/OctopusDeploy/Octopus-Tools
2016-01-13T21:18:36.4871816Z Exit code: -1
2016-01-13T21:18:36.7996773Z ##[error]Unexpected exit code -1 returned from tool Octo.exe

I can’t spot what I am doing wrong

Hi Stuart,
Looking at the error message it looks like octo.exe is expecting the apiKey to be passed in as a parameter on its own, not through the username and password. Could you shoot through a screenshot of your configuration for this task so that I can take a quick look and confirm if it needs to be configured correctly.
Thanks in advance,

Thanks for the reply. I managed the resolve it in the end. I had modified the values in the release setup but was redeploying the same release. Once I created a new release the updated values were pulled in and everything worked.

I have the same issue. I’m not sure what the fix was either, but the extension doesn’t seem to be retaining the username/password.

“C:\agent\tasks\OctopusPush\1.2.81\Octo.exe” push --server=cobi2:9200 --user="" --pass="********" --package=""

It seems like octo.exe wants an --apikey parameter, which is not supplied.

Hi Jacob,
As noted in our octo.exe documentation and previous comment in this very post, it currently requires the APIKey. Please provide an API key to perform the request. I have added a github ticket to investigate and update a change to support using the --username and --password parameter.

I have an API key, but am using the TFS plugin. The username and password field was filled out as the documentation describes. Still, however, the —apikey parameter was not set. I just set it manually as a custom parameter and it works now. The only downside is that now my Octopus API key is sitting in plain text on the TFS build.

Hi Jacob,
I’m glad to hear you got it working.
Letting services interact with your Octopus deploy instance is what Service Accounts have been provided for. By creating a user as a Service Account you can ensure that its cannot be used to access the server via the portal, while still giving it the fine grained access that it needs to do its job via API Keys and specific permissions. I would not reccomend using your own API key from your user account since it presumably has alot more access then you would prefer to expose.
I am assing the documentation you are referring to is this one? We do point out there that it does need to be an API Key but let me know if you have read otherwise elsewhere.
Let me know if you have any further questions around this.

I’m sorry I was unclear in my last message. I am using the API key, but the TFS plugin has a username and password column. The video said to put N/A in the username column and put the APIKey in the password section. That is what I did and that is what is throwing the error message.

My workaround was to put the APIKey in the command args section manually. I don’t have the TFS instance in front of me (It’s a local instance at work) so my nomenclature might be a little off. Let me know if you would be interested in investigating this bug. Otherwise, you can go ahead and close this ticket.

Hi Jacob,
We are a little unsure about which video you are referring to. Could you point us towards where saw these details. Is it possible that the wrong api key was pasted into the field? We would love to get to the bottom of this to make sure no-one else hits the same confusion you do.
In any case I’m glad to hear that you have your deployments working succesfully now.

One sec. I’ll look for the video. It’s not possible that the wrong API key was pasted since I looked at the output and it did not use the —apikey flag.

It wasn’t a video after all. It was this tutorial: http://docs.octopusdeploy.com/display/OD/Use+the+Team+Foundation+Build+Custom+Task http://docs.octopusdeploy.com/display/OD/Use+the+Team+Foundation+Build+Custom+Task

Notice how User name is left as N/A and the APIKey is put in the password field. I can show you the exact versions and setup when I am at work tomorrow, Los Angeles time.

It wasn’t a video after all. It was this tutorial: http://docs.

Notice how User name is left as N/A and the APIKey is put in the password
field. I can show you the exact versions and setup when I am at work
tomorrow, Los A

Now that I’m at work, I took a few snapshots for you.

I configured things correctly as described in that article shown in the
attachment Octopus_API_Config.PNG, but I had to do the workaround shown in

I hope that clarifies the approach I took. The TFS version is Version
14.102.25423.0. The Octopus version is 3.5.7.

Hi Jacob,
Thanks for the reply. We do explicitly check for the characters API- at the start of the password field when testing if its an API key or actual password. The source code for this plugin is open source and available here if you are interested. Its possibly that the key you pasted in was missing this part, hence the output woul show it using username and password rather than api Key.
I’m glad to hear that you got your deployments working sucessfully in any case.