Allow each individual determine what deployment emails they want to receive. Users on multiple teams, or large deployment teams, are bombarded with hundreds emails a day. Giving the user the ability to tell the system they only want to receive failures, or no emails at all, would provide a better user experience. Alternatively, if this is not possible, allowing the system to have a single designated email for deployment notifications. This would allow the users to designate something like a Teams Channel to receive the notifications, and cut down on the amount of emails being sent in general.

I find that deployments to Azure Functions and standard app services will occasionally fail due to files being locked. This usually requires stopping the app service, re-running the deployment, and then restarting the function or app.

This can be scripted with Powershell, but since this is such a common scenario, I’d love a checkbox built into the Azure App Service step that provides this ability. Something like “Stop App Service prior to deployment and restart after deployment”.

First I want to say that the new API functionality added in latest versions is very appreciated especially the possibility to export/import project out of spaces. However we really miss the merge functionality when importing project from Non-prod octopus to Prod Octopus

Our current automated procedure includes : Delete project-> Re-import Project-> Update prod variables

Problems: It removes history and require a new release number in prod due to updated of variables.

Addition to this feature requests includes: Exclusion of environment variables in export

As a project leader I should be able to group variables on Octopus UI. This can be just logical separation.

This solve the problem with linked variables and help mange them.

For example It could collapse elements that are in structure - for example: db.username and db.password can be collapse as elements of root db or by labeling variables and then can be filtered by using specific label, for example - db.

Add ability to define custom substitution filters that can run scripts defined by the end user.

Microsoft opened up a preview for ARM base Azure Cloud Service, which is probably hinting on them moving away from a Classic cloud service deployment model:
https://docs.microsoft.com/en-us/azure/cloud-services-extended-support/overview
Please add support for this type of targets.

Currently the home dashboard displays tenants as a small grey-on-grey count of up-to-date tenants vs total tenants. It would be nice to see a coloured pie chart or similar visualization instead, to make it more obvious when one tenant in an environment is still running an old version or has had a failed deployment.
It can be easy to miss failed deployments from the dashboard screen.

Instead of only allowing explicit tenant selection, add the ability to select the tenants to execute the runbook for by their tenant tags when adding an new scheduled trigger.

Add an option to have guided failures timeout out and fail after a specified period of time. I.E it no manual intervention is taking in 1 hour have the deploy fail completely.

Some steps in the deployment process could merely be just to trigger some notifications or sending metrics to other products. These steps are not critical to the deployments.
A flag in the step could be helpful which can mark it as a critical/non-critical step

The only Runbook trigger right now is a scheduled trigger.

I would like to suggest two more trigger types:

Helm Chart Package Trigger:

When a new Helm Chart version of a package is published, then the trigger would fire. (Allowing the calling of a Runbook.)

Version Control Trigger:

If Octopus Deploy added a VCS trigger, then it would allow us to use GitOps.

Both of these allow Operations to enable control from check in / merge point in source control.

Parallel execution should be enabled or can be switch on the fly in script console. Via a variable, similar to OctopusBypassDeploymentMutex

With the scenario that there is a process running (read: stuck/looping) in the target and executing a kill command via the script console will get you “waiting for script to finish in task…” so it is currently not the workaround.

Ref case:
https://help.octopus.com/t/force-stop-a-step-execution/26682/3

We are currently using React, Gatsby and Parcel which all use .env files for their environment variables

https://www.npmjs.com/package/dotenv

Currently .env files are not being recognized, they are assuming they are yaml files, which they are not, they are read similar to java properties as key values

Right now we have to use variable substitution, but would like to use structured so we don't need to add #{} tags in our code

Several packages are now incompatible with FSI as it uses the old execution engine, one example is FSharp.Data and latest Newtonsoft.Json. System.Text.Json is also out of the question, basically anything targeting Netstandard 2.0.

Switching to dotnet fsi will allow usage of said packages. It will also ensure cross platform compatibility for scripts and allows referencing packages in the script. https://devblogs.microsoft.com/dotnet/f-5-and-f-tools-update-for-june/