octopusdeploy / octopusclients

| Public | Octopus.Client for commanding Octopus servers

This repository contains the .NET Client Library (Octopus.Client) for Octopus Deploy, an automated deployment server for professional .NET developers. You can use it to create and deploy releases, create and push packages, and manage environments.

Octopus.Client is available on nuget.org

Documentation

• Octopus.Client

Issues

Please see Contributing

Development

You need:

• VSCode, Visual Studio 2017 or JetBrains Rider to compile the solution
• dotnet core 2.2 SDK

Run Build.cmd to build, test and package the project. Do this before pushing as it will run the public surface area tests as well, which require approval on every change that modifies the public API.

Releasing

Note: releases can only be performed by Octopus staff. To release to Nuget, tag master with the next major, minor or patch number, TeamCity will do the rest. Kick off the Create OctopusClients Release build again if any of the dependencies fail.

This will push the release to our Octopus server, and trigger the Octopus.Client project in the integration space. A deployment will automatically happen to the Extensions - Internal environment, and publish the package to Feedz.io. Once ready to be fully released, promote the release to the Extensions - External environment.

Compatibility

See the Compatibility page in our docs

Versioning

We use Semantic Versioning for our open source libraries and tools. This breaks with our older practice of keeping version numbers in sync with Octopus Server.

Within a major version of Octopus.Client we will maintain backwards compatibility to a set version of Octopus Server, allowing worry free minor and patch upgrades.

Conversely we also maintain backwards compatibility in our Server API as much as possible while still being able to add new features. This means that an older version of Octopus.Client will work with newer versions of Octopus Server.

Refer to our Compatibility page to get an overview of which versions work with a particular version of Octopus Server.

octopusclients's Issues

Add a --timeout option

We are actually uploading a nupkg which is more than 40MB. It can takes more than 10 minutes depending on the load.

A --timeout option is missing on octo push, since we are limited by the ApiDefaults.cs values, which seems to be set to 10 minutes.

I can submit a PR, but I want to be sure you are interested in this feature, and that the octopus API does not have a similar timeout lock.

Port to .NET Core

Related to OctopusDeploy/Issues#2696

• Ensure timeout still works

Expose our JsonSerialization converter classes so users can leverage them in their own code

We have had a customer report an issue when trying to deserialize the DeploymentProcessResource using Newtonsoft.Json with the default serializer due to that we use custom resource converters and they're all marked as internal. It might be a good idea to make them available for customers to use in their own code.

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

ProjectEditor.SetLogo() and TenantEditor.SetLogo() should be async

The SetLogo() method on the async versions of ProjectEditor and TenantEditor don't seem to work, and don't await the result of the upload. They should be changed to correctly await the logo upload task, and then return the Editor.

OctopusAsyncClient ctor initializes the Repository too early

The Repository can only be initialized after the client established a session.

Remove `--status` option

• DeploymentTemplateStep.MachineNames
• MachineModelStatus
• MachineResource.Thumbprint
• MachineResource.Uri
• MachinesResource.Status

Potentially breaking change in Octopus.Client dependency - ServerCertificateCustomValidationCallback & SslProtocols

We plan to release new System.Net.Http package which will break two APIs you use HttpClientHandler.ServerCertificateCustomValidationCallback and HttpClientHandler.SslProtocols - (usage in your code 1 and 2).
The reason is that the package causes a lot of grief to .NET developers (see https://github.com/dotnet/corefx/issues/11100), we have to revert the source code back to 4.6 code and there is no simple way how to implement this property correctly in that code base.

The breaking change (more details in https://github.com/dotnet/corefx/issues/11100 - see top-most post, section 'Impact of the change - Breaking changes'):

.2. HttpClientHandler.SslProtocols (introduced in System.Net.Http 4.1)

• New behavior: Throws PlatformNotSupportedException
• Workaround: Use ServicePointManager.SecurityProtocol instead (impacts the whole AppDomain, not just single HttpClientHandler as it did in System.Net.Http 4.1-4.3)

.3. HttpClientHandler.ServerCertificateCustomValidationCallback (introduced in System.Net.Http 4.1)

• New behavior: Works fine, except that the first parameter of type HttpRequestMessage is always null
• Workaround: Use ServicePointManager.ServerCertificateValidationCallback

Octopus.Client NuGet package is one of 4 NuGet packages directly affected by the breaking change in the APIs. Can you please assess if your library is affected and act accordingly?

Thank you and sorry for the inconvenience!
If you have any questions, please let us know.
cc @davidsh

Fixed PackagesFolder not finding .nupkg files

octo.exe --packagesfolder is not currently recognizing nuget packages

Provide as a DotNetCLITool (dotnet-octo)

With the new dotnet cli there is the possibility of creating custom cli tools for use during build. It would be great if the octopus client could be published as a simple tool, to expose for example dotnet octo pack and dotnet octo push (for pushing zip files, which nuget can't handle).

I have experimented with the Octopus.Client nuget and a small command line program, and it works very well. It would probably be better to use the octo.exe project as a basis, so it would have the same features.

Option to skip steps in create-release

I've got an automatic deployment to an internal debug environment that should skip steps that are wanted for the non-automatic deploys. Unfortunately, at the moment there doesn't appear to be a way to ignore steps in a release with the API.

Octo.exe List-LatestDeployments returns all deployments and not just the latest

See OctopusDeploy/Issues#2922

auto versioning doesn't increment

When a version is not given octo selects the highest package version, but it doesn't increment the minor part it if there is already one with the same version.

The --ignoreexisting option is not Project specific and will skip creating releases if a Project with the same version # already exists

When using the --ignoreexisting, Release creation will fail of ANY project has a Version # that is the same as the one you're trying to Create.

Example:

Project Current Release Version
Proj-A 9.0
Proj-B 8.0

If I try to Octo.exe create-release --project=Proj-B --version=9.0 --ignoreexisting I will get a message of 'A release with the number 9.0 already exists' even though Proj-B does not have a 9.0 release.

octo.exe pack without a --version argument fails

The code path causes a SemanticVersion to be created in a way that doesn't preserve the OrignalString value.

Source: http://help.octopusdeploy.com/discussions/problems/49836-octoexe-pack-fails-without-version

DeploymentStatusCheckSleepCycle and DeploymentTimeout are not defaulted for the Promote Release command

Unlike the create-release and deploy-release command, the defaults for DeploymentStatusCheckSleepCycle and DeploymentTimeout options in promote-release are not set. The help documentation says there is a default.

Package resolution does not resolve based on packageId when a default is supplied

When using the --package parameter, and a default is specified, it does not fall back to matching on PackageId before using the default.

Exporting project does not export all associated variables

When exporting a project using octo.exe only variables directly associated with the project gets exported.

If you have created server-level variable-sets (for easier re-use) and included them selectively in your projects the export contains no variables at all.

octo.exe export  --server=http://example/ --apiKey="API-EXAMPLE" --type=project --filePath=project.json --name="Example Project"
Octopus Deploy Command Line Tool, version 2.4.9.22

Handshaking with Octopus server: http://example
Handshake successful. Octopus version: 2.4.8.107; API version: 3.0.0
Finding exporter 'project'
Beginning the export
Finding project: Example Project
Finding project group for project
Finding variable set for project
Finding deployment process for project
Finding NuGet feed for deployment process...
Finding NuGet feed for step Deploy Example
...
Export file project.json successfully created.

The resulting project.json contains an empty variable-set:

  "VariableSet": {
    "Id": "variableset-projects-1",
    "OwnerId": "projects-1",
    "Version": 0,
    "Variables": [],
    "ScopeValues": {
      "Environments": [
        {

As you can see, the variables array is completely empty.

Would adding the ability to export associated variables, or just server-level variable-sets be an option?

command line parameter not validated

A minor issue, but it had me scratching my head for a while.
I used --deploy-to rather than --deployto
it says it has deployed:

Release created successfully!
Deployment has finished succeessfully

but it doesn't actually deploy.
--deployto does though.

Remove workaround for HttpClient Bug

When a HttpClient (4.2.0?) is released that fixes https://github.com/dotnet/corefx/issues/11456 remove the COREFX_ISSUE_11456_EXISTS compiler flag and the workaround that it enables.

Variables: bulk import from .config

From this suggestion

Add the following command to Octo.exe:

octo import-variables --from=web.config --project=MyProject

This would:

1. Open the config file specified in --from
2. Grab app the appSettings and connectionStrings
3. Use the API to create variables underneath the specified project

A flag could be used to tell Octopus to create a copy of the variable per environment or not (environment would be null).

Re-enable the `ignoreSslErrors` command line option

In Octo.exe 4.0 support for the ignoreSslErrors command line option was dropped due to HttpClient not supporting it. It will support it in 4.2.0, so when that is released flip on the HTTP_CLIENT_SUPPORTS_SSL_OPTIONS compiler option to re-enable this feature.

Also check that Octopus.Client.IgnoreServerCertificateCallback logs to output correctly.

Channels.FindAll is not implemented on the server

Started by: https://secure.helpscout.net/conversation/339334507?folderId=557077

Async Client does support buffering or chunking on file upload

HttpClient doesn't support it, so this https://github.com/OctopusDeploy/OctopusClients/blob/3.5.4/source/Octopus.Client/OctopusClient.cs#L432 functionality was not added to the AsyncClient

Package Option Actually Expects Step Name

In the documentation it says to specify the package name and version but in the code when it looks up the version it is looking for step name:

This causes issues if your step name does not match your package name. For example:

Step Name: Deploy MyService
Package Name: MyCompany.MyService

passing -package=MyCompany.MyService:2.0.0 -defaultPackageVersion=1.0.0

Will result in the release trying to use MyCompany.MyService.1.0.0 instead of 2.0.0.

Flag to ignore release

I am suffering the bar request exception at the moment.

I have a build chain in TeamCity which deploys to dev using Octopus, now there is no way (that I can tell) to skip a build if it same build number has already been created.

I would like to add a flag (or change default behavior) to ignore the --create-release if it already exists. Instead of The remote server returned an error: (400) Bad Request. Bad Request I would love to see 1.1.0.150 already exists, skipping deployment

Thoughts?

[09:54:14][Step 2/2] Handshake successful. Octopus version: 0.9.620.4
[09:54:14][Step 2/2] Finding environments...
[09:54:14][Step 2/2] Finding steps for project...
[09:54:14][Step 2/2] Getting package versions for each step...
[09:54:17][Step 2/2] 1. GmsServices.Web - latest: 1.1.0.150
[09:54:17][Step 2/2] A --version parameter was not specified, so a version number was automatically selected based on the highest package version: 1.1.0.150
[09:54:17][Step 2/2] Creating release: 1.1.0.150
[09:54:17][Step 2/2] The remote server returned an error: (400) Bad Request. Bad Request
[09:54:17][Step 2/2] System.Exception: The remote server returned an error: (400) Bad Request. Bad Request
[09:54:17][Step 2/2] at OctopusTools.Client.OctopusSession.ReadResponse(WebRequest request)
[09:54:17][Step 2/2] at OctopusTools.Client.OctopusSession.Create[TResource](String path, TResource resource)
[09:54:17][Step 2/2] at ProjectExtensions.CreateRelease(IOctopusSession session, Project project, List'1 latestVersions, String version, String releaseNotes)
[09:54:17][Step 2/2] at OctopusTools.Commands.CreateReleaseCommand.Execute()
[09:54:17][Step 2/2] at OctopusTools.Infrastructure.CommandProcessor.Process(String[] args)
[09:54:17][Step 2/2] System.Exception: The remote server returned an error: (400) Bad Request. Bad Request
[09:54:17][Step 2/2] at OctopusTools.Client.OctopusSession.ReadResponse(WebRequest request)
[09:54:17][Step 2/2] at OctopusTools.Client.OctopusSession.Create[TResource](String path, TResource resource)
[09:54:17][Step 2/2] at ProjectExtensions.CreateRelease(IOctopusSession session, Project project, List'1 latestVersions, String version, String releaseNotes)
[09:54:17][Step 2/2] at OctopusTools.Commands.CreateReleaseCommand.Execute()
[09:54:17][Step 2/2] at OctopusTools.Infrastructure.CommandProcessor.Process(String[] args)
[09:54:17][Step 2/2] at OctopusTools.Program.Main(String[] args)

Re-enable the `ignoreSslErrors` command line option for the .NET 4.5 build of Octo.exe

Now that we have a .NET 4.5 build of Octo.exe (again), we can re-enable this option in just that build (Windows 32bit).

The Linux and portable (dotnet core) builds will not have this option (see #86).

The seconds portion of the deploymenttimeout Octo.exe parameter is ignored

Octo.exe is currently getting the total minutes from the deploymenttimeout parameter, which means that if the value is less than one minute, 0 minutes is passed to the WaitForCompletion API, which represents Never.

Channel parameter for octo.exe promote-release command

Adding a --channel parameter to octo.exe promote-release would allow the latest release for a given channel to be promoted.

As requested by http://help.octopusdeploy.com/discussions/questions/11053

Incorrect documentation for authenticated requests.

The readme shows authenticated requests using the option "--password=". The tool actually expects "--pass=".

Output verbosity of logger

It would be nice if we could configure the Serilog log level as an argument to octo.exe.

Right now, the pack command (when adding a large directory) writes a lot of debug messages for Adding file which I'm not interested in.

If this is something that you think is worth having, I would glady contribute a pull request.

Query string appended twice

Looking at optimizing some of the api calls, and noticed that the ids query string is being appended twice:

From Fiddler:

GET /api/libraryvariablesets?ids=LibraryVariableSets-23,LibraryVariableSets-21,LibraryVariableSets-42,LibraryVariableSets-41?ids=LibraryVariableSets-23,LibraryVariableSets-21,LibraryVariableSets-42,LibraryVariableSets-41

In this example I'm using the async repository and calling LibraryVariableSets.Get with the four id's.

Not causing any problems, just thought it might be worth looking into at some point.

Infinite loop with delete-releases

I'm using octo.exe to delete a specific release but the tool gets into an infinite loop within the Execute method of the DeleteReleasesCommand ApiCommand class.

It is caused by GetReleases ignoring the skip parameter, (see line 51):

var releases = Session.GetReleases(project, skip, take);

The release variable always contains the same number of elements regardless of the skip parameter. This call is made inside a while(true) statement which only breaks when the count of releases is zero, which never happens.

Exe fails in deployment. Exit code 1.

I'm trying to execute FluentMigrator (Migrate.exe) in a PostDeploy script. It runs fine via Tentacle.exe in the command prompt. But via the deployment it just fails for no reason, exit code 1, a successful execution should return 'Task Completed', this just seems to stop.

Calling PowerShell script: 'C:\Octopus\Applications\Development\MVCConsole.Migrations\1.0.6.0\PostDeploy.ps1'
2013-06-19 16:59:52 INFO Run migration: --connection "Data Source=xxx" --provider sqlserver --assembly MVCConsole.Migrations.dll --verbose=true --task=migrate:up --output --outfile ..\migration_2013-6-19_17-59-51.sql
2013-06-19 16:59:52 INFO Migration finished. Exit code 1. ------------------------------------------------------------------------------- =============================== FluentMigrator ================================ ------------------------------------------------------------------------------- Source Code: http://github.com/schambers/fluentmigrator Ask For Help: http://groups.google.com/group/fluentmigrator-google-group ------------------------------------------------------------------------------- [+] Using Database sqlserver and Connection String Data Source=xxx
2013-06-19 16:59:52 INFO File written to ..\migration_2013-6-19_17-59-51.sql

Bit stumped where to go now.
Thanks.

Delete-Releases repeatly displays the same data

After Updating Octopus Server to Version 1.1.3.1410, the behaviour of 'delete-releases' appears to be broken. When the --whatifflag is used I would see a list that kept on repeating the same 20 versions.

[Whatif] Version 12.12.258.0 would have been deleted
[Whatif] Version 12.12.337.9 would have been deleted
[Whatif] Version 12.12.333.2 would have been deleted
[Whatif] Version 12.12.333.1 would have been deleted
[Whatif] Version 12.12.333.0 would have been deleted

'Octo.exe' would end up running for a few minutes before giving up.

Steps to reproduce

1. Make sure Octopus Server is Version 1.1.3.1410 or greater
2. Make sure you have several releases created for a particular project (I had around 40).
3. Attempt to use Octo.exe delete-releases ... --whatif

Expected behaviour

'Octo.exe' to output a list of versions within the min version to max version range and then exit.

Add ability to update release variables from octo

Sometimes the variable snapshot for a release and the current variable set for the project do not match. Add the ability to update the release variable snapshot to the current project variables when deploying a release with octo.exe

octo.exe error

Hello,

After numerous successful Octo.exe operations, we've started getting 400s from the server:

[14:43:50]Handshaking with Octopus server: http://10.12.10.175:8066/api
[14:43:50]Handshake successful. Octopus version: 0.9.620.4
[14:43:50]Finding environments...
[14:43:50]Finding steps for project...
[14:43:50]Getting package versions for each step...
[14:43:50]1. ConstellationWeb - latest: 0.105
[14:43:50]A --version parameter was not specified, so a version number was automatically selected based on the highest package version: 0.105
[14:43:50]Creating release: 0.105
[14:43:51]The remote server returned an error: (400) Bad Request. Bad Request
[14:43:51]System.Exception: The remote server returned an error: (400) Bad Request. Bad Request

(Above is a log from teamcity)

Are there logs on the server that can be examined? Any advice on a fix or workaround?

thanks!
Steve

NullReferenceException when creating release

Whenever I try to create a release with octo.exe, an unhandled NullReference exception gets thrown in UriExtensions.EnsureEndsWith(). The complete execution of the tool looks like:

octo create-release --project=PROJECTNAME --server=http://SERVER/api --version=0.5.1257.3000 --deployto=Continuous_Integration --force --apikey=KEY

Octopus Command Line Tool, version 1.0.15.42

Finding project: PROJECTNAME
Handshaking with Octopus server: http://SERVER/api
Handshake successful. Octopus version: 1.0.15.1251; API version: 1.0.0
Finding environments...
Finding steps for project...
Getting package versions for each step...
Core.Database - latest: 0.5.1257.3000
Core.Database.TestData - latest: 0.5.1257.3000
Audit.Database - latest: 0.5.1257.3000
Audit.Database.TestData - latest: 0.5.1257.3000
Elmah.Database - latest: 0.5.1257.3000
Elmah.Database.TestData - latest: 0.5.1257.3000
Core.Web - latest: 0.5.1257.3000
Creating release: 0.5.1257.3000
POST http://SERVER/api/projects/projects-1/releases
Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an obj
ect.
at UriExtensions.EnsureEndsWith(Uri uri, String suffix)
at OctopusTools.Client.OctopusSession.Get[TResource](String path)
at OctopusTools.Client.OctopusSession.Create[TResource](String path, TResourc
e resource)
at ProjectExtensions.CreateRelease(IOctopusSession session, Project project,
List`1 latestVersions, String version, String releaseNotes)
at OctopusTools.Commands.CreateReleaseCommand.Execute()
at OctopusTools.Infrastructure.CommandProcessor.Process(String[] args)

I've tried adding and removing various parameters, but keep encountering the same issue.

.NetCore and using Octo.cmd

Hi, I try use Octo Command Line in our CI (.Net Core version) but I think Octo.cmd needs correct. You don't pass arguments from bash to dotnet Octo.dll. Consider change this to dotnet Octo.dll %*

Octo deploy-release does not show progress

--Force parameter not working?

I'm trying to use the --Force parameter so that I don't have to constantly increment the version number to perform test deployments of a Nuget package. Unfortunately, it seems to fail out when I try to do a repeat deployment (same version # with --Force).

Octopus Command Line Tool, version 1.0.0.0

Finding project:
Handshaking with Octopus server:
Handshake successful. Octopus version: 0.9.620.4
Finding environments...
Finding steps for project...
Getting latest package versions for each step...

1. - latest: 2012.3.8.15
   Creating release: 2012.03.08.18
   The remote server returned an error: (400) Bad Request. Bad Request
   System.Exception: The remote server returned an error: (400) Bad Request. Bad Request
   at OctopusTools.Client.OctopusSession.ReadResponse(WebRequest request)
   at OctopusTools.Client.OctopusSession.Create[TResource](String path, TResource resource)
   at ProjectExtensions.CreateRelease(IOctopusSession session, Project project, List`1 latestVersions, String version, String releaseNotes)
   at OctopusTools.Commands.CreateReleaseCommand.Execute()
   at OctopusTools.Infrastructure.CommandProcessor.Process(String[] args)

Cheers,
Trevor Sullivan
http://trevorsullivan.net
http://twitter.com/pcgeek86

Wait for deployment flag only seems to work on create-release, not deploy-release

Force no longer supported?

Trying to use the --force (as we had before and as documented) in the new Octo 2.0 tool, but it gives the below error. I just want to make sure to execute the package again (we have versions anyway). Is it no longer supported or do I need to use another command?

"octo.exe" create-release --deployto="Test" --force --version="1.26.27.127" --packageversion="1.26.27.127" --project="AerData.Stream.Bus" --server="http://sv-ad-ap02.aerdata.loc:81/api" --apiKey="API-(removed)"
Octopus Deploy Command Line Tool, version 2.0.5.18

Unrecognized command arguments: --force
Exit code: -1

Timeout when creating release

Not too sure if this is the right place but I'm getting this issue about 50% of the time when my build server tries to create a new release.

Build server pushed up the nuget package to server then calls the octo.exe function to create the release straight away. This fails half the time but then running the same command some time after is always successful.

Here is the log from the build.

"C:\NuGet\NuGet.exe" pack "C:\Builds\Temp\FitCloud.Web\3397\FitCloud.Web.nuspec" -OutputDirectory "\\grp-dev02\f$\Websites\Ardent.NuGet\Packages"  -basePath "C:\Builds\Temp\FitCloud.Web\3397" -Version "0.1.3397" -NoPackageAnalysis
  Attempting to build package from 'FitCloud.Web.nuspec'.
  Successfully created package '\\grp-dev02\f$\Websites\Ardent.NuGet\Packages\FitCloud.Web.0.1.3397.nupkg'.
  "C:\Octopus\Octo.exe" create-release --server=http://octopus.ardentleisure.com/api --apikey=C8CENDNLW1XYMCGJ9CHSPR9YOHM --project=FitCloud --deployto=Dev
  Octopus Command Line Tool, version 1.0.0.0

  Finding project: FitCloud
  Handshaking with Octopus server: http://octopus.ardentleisure.com/api
  Handshake successful. Octopus version: 1.0.13.13; API version: 1.0.0
  Finding environments...
  Finding steps for project...
  Getting package versions for each step...
  The operation has timed out
  System.Net.WebException: The operation has timed out
     at System.Net.HttpWebRequest.GetResponse()
     at OctopusTools.Client.OctopusSession.Get[TResource](String path)
     at OctopusTools.Client.OctopusSession.List[TResource](String path)
     at ProjectExtensions.GetLatestPackageForStep(IOctopusSession session, Step step)
     at OctopusTools.Commands.CreateReleaseCommand.Execute()
     at OctopusTools.Infrastructure.CommandProcessor.Process(String[] args)

octo.exe export command fails to export in v4.0.4

Due to a bug in the recent changes to use the async model when making HTTP requests as part of the move to .net core, the export command appears to have broken.

When octo.exe export command is invoked with the correct arguments, it exits with exit code 0 but with no export taking place.

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

Add global.json config

This project uses the dotnet SDK preview2 format (project.json / xproj).

To be compatible with VS 2017, it needs a global.json config file which locks the SDK used to the preview2.

See this SO question and this blog post for details.

I will submit a PR.

"Cannot be deployed to environment" error because I specify a different lifecycle for the channel

.\octo.exe create-release --project="$project" --channel $channel --server https://standley.channelnet.com/ --apiKey $apiKey --waitfordeployment --deployto 'QA2' --progress

Release '20161223.002' of project 'xxxxxx' cannot be deployed to environment 'QA2' because the environment is not in the list of environments that this release can be deployed to. This may be because a) the environment does not exist, b) the name is misspelled, c) you don't have permission to deploy to this environment, or d) the environment is not in the list of environments defined by the lifecycle.

While it's true that QA2 doesn't exist in the default lifecycle, I'm deploying to a Channel that has a different lifecycle. I think that octo.exe is not smart enough to handle this.

Notice: AntiVirus thinks Octo.exe is a virus

This isn't really a bug or an issue, just thought I would flag up that WebRoot SecureAnywhere classifies octo.exe as "W32.InfoStealer.Zeus"

An endpoint has recently detected an infection:

Infection List:
OCTO.EXE, W32.InfoStealer.Zeus, ?:\tools\new folder\,

If you're noticing that the exe disappears the first time you execute it, antivirus might be the cause.

Using octo.exe pack with an extension-less file does not add file to nuget

If you run octo.exe pack id=something on a directory that has a file without an extension, it is not added to the nuget package. This is confirmed by inspecting the package afterwards with Nuget Package Explorer.

I found that the only way I could add such a file to my package was to add it to the package manually using Nuget Package explorer.

Variables: Import/export as CSV

It's not fun to deal with lots of variables. See this discussion for example.

Instead of building an all-singing, all-dancing, bulk variable editor, let's just provide the ability to export variables to CSV, edit them, and import them again. Then people can use Excel or Vim or whatever they like.

Save configuration

Hey,

It would be great if the Octo.exe tool could pull its Api Key (and Octopus API Url) from a configuration file - instead of having to specify them each time.

That way, deployments using octo.exe can be done with fewer parameters from the command line and removes resistance to interacting with the service.

Cheers,
Andrew