Have another column for the project variables for notes/documentation. This would allow for information about what the variable is for, possible lists of valid choices, what those settings do. Most are self explanatory, but some do need additional documentation and it is better than keeping this info in a separate location.

We had an issue where Azure changes out our network card which caused octopus to hang waiting for the interface to come back online as if the cable was just unplugged. As the interface was changed this meant the service hung until it was restarted. We would like to see octopus handle this better / perhaps crash out when the network goes away for a longer bit of time so that the service can restart on its own and pick up the new network.

In powershell scripting we have the following method call…

New-OctopusAzureWebAppTarget

found in https://github.com/OctopusDeploy/Calamari/blob/master/source/Calamari.Shared/Integration/Scripting/WindowsPowerShell/Bootstrap.ps1

This (and others) do not exist for scriptcs

found in https://github.com/OctopusDeploy/Calamari/blob/master/source/Calamari.Shared/Integration/Scripting/ScriptCS/Bootstrap.csx

Make scriptcs a first class citizen for Octopus Deploy.

Add a button on the audit log screen to restore deleted items. I am specifically looking for the ability to restore deleted process steps or other unintended changes to the configuration.

It would be helpful if you could have the Tenant name display on the Infrastructure page under Deployment Targets instead of hovering.

On the Deploy Release screen, if you have multiple Tenants selected, you see, per Tenant, if there are any “Unavailable” Tentacles for that tenant. We would like it to also show how many “Unhealthy” Tentacles there are, ideally as a separate, less severe (yellow?) classification.

We run automation on our projects and found that each project does not have a unique identifier. The slug should be unique but we've found that when the project name has been renamed, the slug changes as well.

It would be nice to have some unique id that cannot be changed.

I think it would be nice to have this feature on Octopus.
So I was given a deployment task and I had multiple environment variables to upload.
I am the lazy type so instead, I wrote a python script to enable me to upload all at once in just a sec.

I hope this saves someone too

https://github.com/opemipoVRB/Python-Octopus-Client

Azure allows for the deployment of Subscription level resources via a template, but currently there is no out of the box step to do this in Octopus.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/deploy-to-subscription

It would be great if we could have a built in step, along the same lines as the 'Deploy an Azure Resource Manager' template step.

So sensitive project variables will be referenced from Azure Key Vault instead of being stored in octopus.

https://azure.microsoft.com/en-us/services/key-vault

3357461 - 'Azure Resource Manager Key Vault support' was only about ARM template Key Vault support.
17973586 - 'Integrate Octopus deploy with secrets managment system Vault' is similar to this issue only for https://www.vaultproject.io

This idea is similar to
https://docs.microsoft.com/en-us/vsts/build-release/concepts/library/variable-groups?view=vsts#link-secrets-from-an-azure-key-vault-as-variables

I can understand for performance reasons wanting to restrict the audit form, but it's incredibly frustrating to use the existing interface to find the creation date of an object when the date filter refuses to go away, and in fact seems to want to shrink to 1 month when wrestled with.

I'm willing to wait a few seconds for the information I want. Just show it to me.

If you deploy to specific targets in an environment but one the steps triggers a chained deployment, the chained deployment will target all hosts in the environment. It would be better if the chained deployment continued to target only the specific hosts that were originally chosen.

Sometimes we just want to write out a simple file to disk. For example writing out a basic text file to a location. While you could have a basic template in an repo sometimes you want to write out a straight file to disk with the normal support for variable substitution. Example, write a file to a queue or change a basic configuration file.

When setting up a new ARM template for use in octopus we set the default value of all parameters to #{something} so that the 'parameter' page in octopus is auto populated.This works great for most values but if we have a secure string octopus will update the 'default value' in the arm which will show up in the deploy history in Azure. We would like to see some way to handle this so we can ignore updating the default value or auto-populate the parameters page without needing the default value or some other way to handle this a bit cleaner.

The nuspec approach may indeed support excluding files. However the zip approach (--format=zip) doesn't. Per octopus documentation the .zip approach is the recommended way forward. In this light a --exclude option is in order to compensate feature-wise vS the nupkg approach.

The Service Fabric Mesh deployment model is in public preview since a couple of months back and GA is expected this spring. Being mainly ARM template and container based, the SF Mesh deployment is probably possible to accompish by custom scripts today, but good out of the box support in OD would be very valuable.