The basic request comes down to having a checkbox on the Deploy Package step to prevent Octopus from unpacking a NuGet/Zip/Tar file after pushing it to the target server.

Package to deploy: PackagerName 1.2.4
Target roles: MyServerRole
[x] Do not extract package after push

I'll dig a bit deeper on the reasoning behind the request.

We have a solution we'd like to deploy to a deployment pipeline which we receive from an external vendor. They provide a NuGet feed with their packages. One of these packages contains the installer code and all configuration templates, the other packages are validated and deployed using their installer. The installer expects the NuGet packages to be in an unextracted form.

Our constraints:
* Given that this is a 3rd party solution, we do not have control over their packages.
* We do not want to repackage every NuGet package in a Zip package prior to deployment, as this would require us to pre-emptively download and re-package every file we might want to deploy. For deployment of in-house developed solutions I can see this to be a valid workaround, but for 3rd party feed sources, it's not feasible.
* We do not want to intercept the NuGet package during the deployment. We want to skip this step altogether. While a nice workaround, some of the packages are of considerable size and extraction would add 10's of minutes to each deployment.
* We've considered using the "Offline package drop" target as a workaround, while this comes close, it requires us to open up SMB from the Octopus Deploy server to the target environments. Having these ports open to the target environment adds a large additional security surface to each exposed server.

We understand that pushing a package and not extracting it would not allow us to run embedded scripts. This is what we desire.
We would like to be able to run the scripts configured on the step properties, since we deliberately choose not to extract the package our scripts are aware that the packages are dropped in package form.

Looking at the Octopus Deploy forums, then we are not alone in this request:

* http://help.octopusdeploy.com/discussions/questions/6581-copy-package-to-tentacle-server-without-deployment
* http://help.octopusdeploy.com/discussions/questions/7661-accessing-package-without-deploying-it

I see this question - http://help.octopusdeploy.com/discussions/questions/8083-automatic-user-login but this indicates it would go through something like OAuth. The already built in Kerberos/NTLM integration is really nice and I'm not sure why there isn't already an option to have the octopus deploy site initiate an auth challenge on page load rather then when you click the button. This is how Klondike works out of the box and TeamCity calls this "Forced Protocols." Forced protocols is a bad name though as it gives you the option to log out and login as another user - which is useful for keeping separate accounts one user and one admin. Either way this would be cool and really smooth out the experience. For chrome and IE you have to have configured the internal site as an intranet site and for firefox you have to add it to a few trusted uri config settings for this to work - this is done for security.

I know there a lots of requests to make the dashboard more compact and that you're also working on significant changes to it for the upcoming multi-tenancy release. One thing I don't think I've heard mentioned in either conversation is displaying channel information in the dashboard.

It's great that when you drill into a project overview you can pretty easily see what feature is in what environment because the channel is listed on the left. It would even better to get this information on the dashboard so you can see at a high level what components are affected by a certain feature and easily be able to see that they're all deployed to an environment. This is especially helpful when you have lots of components on different versions that need to be deployed in conjunction for the same feature release. This way you don't have to know version numbers for each project by heart which are intended for a particular feature you might be working on.

It would be really nice if octo.exe could make an intelligent decision and automatically select the correct Channel for a Release based on the Version Rules.

As of Octopus Deploy 3.2 you need to explicitly choose a Channel for a Release, unless you intend to use the Default Channel. This doesn't help when you are supporting multiple active versions.

Whilst this wouldn't work for every situation, it would be brilliant if I'm following a strict versioning convention for my packages and Releases, and configured explicit and independent Version Rules, that octo.exe could pick the right Channel.

I would imagine octo.exe would:
1. Have an extra argument like --channelAuto
2. Query the Project for Channels
3. Filter out Channels that don't have Version Rules that match the Release being created
4. If there's only one suitable Channel, use that. Otherwise raise an error explaining there were zero, or multiple Channels that could have been auto-selected, and the user should fix their Version Rules, or specify the Channel explicitly with the --channel argument.