Allow copying of a runbook between projects, or a runbook template across projects, or master runbook view across all projects

Sometimes our task queue is filled with a lot of tasks waiting to be executed. Every once in a while a priority deployment needs to take place at the same time.
In such case It would be very useful if we could mark this deployment as "High Priority", so that the tasks of this deployment are handled before the already existing tasks in the queue.
This is not possible now, the only solution now is to cancel all the existing tasks.

When deploying to c:\mydirectory#{Octopus.Release.Number} Runbooks are unable to obtain the #{Octopus.Release.Number} information from the deployment. Which makes a lot of actions rather difficult.
If it was possible for a deployment to set a variable available to Runbooks or for Runbooks to query information in releases per environment that would really be great.

Streamline data entry

In a given project, see all the other projects that refer to it in a 'Deploy a Release' step.

Use case for this is similar to the Usage tab for a step template. If I create a new release for a sub-project, I want to be able to find each parent project and update them to point to this new release.

The idea is to have the tenant variables displayed vertically, with one column for each environment.
Currently, it is quite tedious to compare or copy variable values from an environment to another.

Currently if we create a release for a project with multiple steps excluding some of the steps, it is not persisting the state when the same release is promoted to the next environment as part of channel life cycle.

We need to exclude the steps again when promoting the same release to next environment which is causing lot of problems as people deploying the release are different for different environments and often they forget.

It would be great if you can persist the state of excluded steps to the next environments as part of same release?

As per - https://help.octopus.com/t/deploy-a-release-accessing-variables-from-last-release/22788

You should be able to access a previous releases Step output variables, for when a release has already been deployed.

Either via the Deploy a release step.
Or more generally to retrieve these values for a given release.
E.g. an obtain Release information step

The deploy release step assumes want to deploy to the same environment as the parent deployment.

Add facility to pass a parameter to chose which environment to deploy the release too.
E.g. so can deploy a single master release, which kicks off multiple deployments of other release to the defined environments specified by the parameters.

Similar to how the community Chain step template allows for.

We deploy our packages to our customer environments.
For example 1.5GB of packages to 500 targets over the internet. As the internet connections can be slow and to make sure that the deployments all take place at the same (scheduled) time I suggest that the "acquiring packages" step optionally starts as soon as a deployment is scheduled and verified again at the scheduled execution time. Should the deployment package(s) be missing or corrupt at the scheduled execution time there could also be an option "re-aquire at execution"/"fail if missing".

Given an JSON settings file which has an array element

e.g. { "Users": [] }

Use Octopus variables to insert into the array rather than just replace values.

e.g.
define Users:0:Username = user
define Users:0:Password = password

Would result in the object getting inserted

{ "Users": [ { "Username: "user", "Password": "password" } ] }

https://help.octopus.com/t/json-configuration-can-it-insert-into-an-array/24317/7

Give an option (or make it default) to have the "Acquire Packages" step to always happen at the very beginning.

Our use case:
We uninstall a program, then extract the package and install it. If it fails on the package download (which happens automatically right before the extraction), then our deployment target had all of its files deleted, but failed the deployment.

Our current fix:
Make sure the "Extract Packages" step is the first thing in every project, to force "Acquire Packages" to be at the very beginning

Please can a view be added that allows a user to see all deployments in a pipeline, spanning all tenants and channels? Having to search for these seperately causes no end of headaches as I often have to line up versions and this is made harder when they have to be searched for. Making it so they are all visible from the main page of a release as an optional view would alleviate this.

Some of our deployments have lengthy steps that cannot yet be automated. It would be great if markdown files contained with in a package can be used as manual intervention steps in a deployment.

I was thinking this could work by simply having an option to choose a file rather than type the instructions on a manual intervention step.

However it would be really great if some naming standard could be introduced. For example "PreDeploy.md" would appear as a manual intervention at the start of the deployment.

Delete previous install files when new install (with an artifact) occurs (offline targets). These deletion should keep in mind the configured retention policy in the corresponding lifecycle

Add the ability to encrypt variable strings using something similar to the variable filters.

Something like: #{VariableToEncrypt | Encrypt(#{CertificateVariable})}

When you configure a "Run a Script" deployment step, you can reference a package, and add the "Substitute Variables in Files" feature. Within the help text it says "A newline-separated list of file names to transform, relative to the package contents." which is inaccurate:

For me, using a simple, relative path here e.g. "index.html" didn't work. I needed to use the full extracted path of the package e.g:

{Octopus.Action.Package[EdibleCode.Something].ExtractedPath}\index.html

Also, you can reference multiple packages for a a run a script template, in which case "relative to the package contents" doesn't make sense and needs clarifying.

When iterating through a collection variable using #{each var in array}, it would be helpful to have a sort by pipe
Eg: #{each var in array | orderby var.property}