Currently the automatic release creation feature does not resolve variables when looking if a package is used in a project set for automatic release creation. You can only use package IDs with static names.

It would be great if you could use variables in the package ID and have them resolved when the package is pushed.

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

At the moment when editing a step, you can specify which environments it is to be run in. Selecting no environments means that the step will run in all environments. There's no way to specify that a step should run in no environments.

If I have a problematic step and I'd like to take it out of use temporarily while I work on it, I'd like to disable it somehow, maybe with a checkbox on the process page.

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

Run the Octopus server completely on top of PaaS offerings. You could use a Web App site extension to install/run the server (an HttpPlatformHandler might be an easy way to utilize the existing windows service executable), an Azure SQL database for the backend, and a blob storage account could be your NuGet package repository.

It would be nice if I could clone steps inside processes. For example if I want to deploy two nuget packages, I need to create one step to deploy a nuget and again create another step to deploy a nuget, instead of just cloning it. It's a waste of time!

I regularly use nested variables to minimise the number of variable changes I must make between environments. Consider something like this:

data source=#{Database.Server};initial catalog=#{Database.Name};#{Database.Auth};

This allows me to just specify simple variables for the DB server, the DB name and the type of auth being used, without having to construct a connectionstring every time (and probably making the odd mistake).

It would be great if I could see the fully-evaluated variables when i click "Show variables" on a release - or at least have a switch between the raw variables and evaluated variables.

It would be great to see Python listed as a script step. Python is heavily utilized in the infrastructure space, AWS, F5, Citrix, VMware and will help to drive full automation further up the stack.

Via @DotNetWise (https://github.com/OctopusDeploy/Issues/issues/1157)

Retention policy helps you to cleanup the mess, but it could possible destroy your live releases.

You DO want to apply retention policy on live servers, but not for those releases you know there are being used / live etc.

Hence, add the ability to lock a release, so it won't be deleted by the retention policies.
Later on, I could unlock it and it will go away on when the next retention policy is being applied.

https://github.com/OctopusDeploy/Issues/issues/447

It'd be awesome if clicking on a Project Group in the Projects drop down took you to a dashboard that ONLY listed the projects under that group.

Better if an admin user can still hide/show projects in those virtual dashboard for everyone

Even better if each user could configure a custom version of that dashboard for themselves

Would like that OD is in compliance with the latest version of SemVer, so that the Pre-Release flag, and Build Metadata can be utilized in the release number.

In some environments we do not want a Windows Service started after it is deployed. In the current Octopus.Features.WindowsService_BeforePostDeploy.ps1 file the service is always started. It would be great to have a flag that could prevent the service from being started.

It would be nice to be able to set random values in the config files using an XmlPoke type feature where you could specify XPath expressions that point to values in the config file and then specify values to set them to.

Here is an example to set the compilation debug to false:

XPath: configuration/system.web/compilation/@debug
Value: false

This would allow setting random values throughout the config file without having to use config transforms.

We have multiple projects being deployed to different servers in heterogeneous environments. Some are just test-production, others are dev-test-staging-production. The projects often have completely separate environments.

It would be beneficial to be able to either choose which environments a project can deploy to, or to be able to set up per-project environments to be able to keep the same names for config transforms. (ex. "Web.Test.cfg" instead of "Web.Test-Product1.cfg")

Currently the Dashboard is also very "cluttered" with empty boxes due to those environments not being in use for certain projects.

In our project we have 2 branches - trunk and patch - both of which produce packages for Octopus and use semantic versioning when creating the Octopus release in the build. I would like to specify a build from the patch branch explicitly so that when packaging off the trunk my release would be 1.24.102948 but when packaging off the patch branch my release would be 1.24.102949+patch. My workaround is to use the pre-release metadata so my patch builds are producing octopus releases 1.24.102949-patch.

Recently we have been audited and one of the questions asked of me was to provide a control for how permissions are managed. At the same time provide me with evidence that you periodically review permission changes using a system generated report. This would be very simple to implement using the same audit structure currently used for the deploy process and it would make auditors happy.

In "Run a Helm update" step we need: Enabled Features -> Substitute variables in files

Why?
For example we need to create configMap for our helm-chart. App config locate in this chart, so we need replase all #{values} by values from project scope

Step helm_install:
1. download chart
2. Substitute variables in files (choose location)
3. in custom script (deployment step) create configMap for our pods

If this feature doesn't exist: we need another step where we download app config and substitute variables and use this file to create configMap