Currently when a new variable set is created, it has to be included in projects individually. When there are many projects that should include the variable set, it would be much more convenient if the set could be included in projects via the 'usage' tab.

I need a step A that set a project level variable #{COLOUR} from powershell and/or bash such that when I run an arm template step within the same deployment the parameter file correctly substitutes the value of #(colour} during the arm template deploy.

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.

We use keyfactor (https://www.keyfactor.com/platform/certificate-lifecycle-automation/) for Certificate lifecycle Automation. It would be great if Octopus could integrate with this keyfactor to allow for issuance, renewal, inventory, import and storage of new certificates.

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”.

When we're doing mass maintenance to an entire environment, it would be useful to be able to disable non-admins from doing things to that environment, and display a banner (e.g."Deployments to production are disabled while servers are being re-racked") without stopping activity in other environments.

Looking for something much like the system-wide maintenance mode, except environment specific.

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

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

In the installation documentation there exists a helm chart example:
https://octopus.com/docs/installation/octopus-in-container/octopus-server-container-linux

Are there any existing examples of doing something similar, but using CloudFormation/Fargate/ECS to run the server + tentacles?

Add a filter search to this dialog, and order the dropdown contents alphabetically.

Version: https://octopus.com/downloads/2020.6.4855

Also put a copy icon next to your version number.

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.

I posted about this as a GitHub issue as well (https://github.com/OctopusDeploy/OctopusCLI/issues/142). Basically, it would be nice if the octo CLI could read environment variables for all of its commands and flags. This would make CI easier since values could be easily changed and tested without having to make code changes.

Thank you!

Project variables may be scoped to a process to differentiate between variables used for deployment and variables used for runbooks.

I would like to be able to define process scope for variables within library variable sets so that library variables intended for use in deployments do not pollute my runbook process.

In our more complex deployment project, we heavily depend on runbooks to update configuration, check parameters, run clean-ups, change certificate, and and and.

It is very hard to keep an overview in a long and unstructured list and it would be immensely helpful if we could organize runbooks a folder structure.

e.g.

|- Certificate
| |- verify chain
| |- change cert
|- Database
| | - create backup
| | - run maintenance
|- Configuration
| | -rewrite config

| | -verify config

... and so on

Make it so we can reorder tenants. We have 200 of them and having to scroll down to find our "Internal" tenant is silly. Renaming it to "0 Internal" to make it appear at the top looks hacky.

Customer has requested we add some basic IP level restrictions to the Cloud instances when accessing via VPNs or other restricted networks