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.

Similar to most other entities in Octopus (e.g. Projects, Machines, Feeds, etc), it would be very helpful if the steps of a deployment process or runbook had an immutable and unique ID in addition to their display name. This would make referencing a step from elsewhere (e.g. reading output variables) a lot more resilient to change over time.

Variable sets cannot be deleted until all project, release, and I assume runbook references are removed. Since it can take a long time for releases to age out, a Depreciate flag that can be set once all Project references are removed would be great. This flag would prevent adding the Variable Set to projects (and hidden from the selector).

Please add support for uploading artifacts also via the user interface.

Uploading reports/approval documents or other files to a release is currently not possible via an upload button. We have to do a workaround using a script that uploads files from a specific folder or using the API to attach files to a release.

Especially during Octopus approval steps people need to upload documents.

The Deployment Trigger should support multi-tenant logic. I am sure I do not have a unique environment that a test/staging environment is in a single tenant and production can span multiple tenants.

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.

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 want to be able to easily store and use other cloud providers. At the moment only Azure and AWS is supported but I want to be able to use others. The ability to create others (such as DigitalOcean) would be brilliant.

I would be happy being able to store the key and secrets and have Octopus set the values in the worker as environment variables that I specify (it would also be very useful to also be able to say that this variable is an environment variable rather than needed substitution).

When filling in a form in Octopus Deploy, for example to add a deployment step or to add new variables, if you resize the window all unsaved data is lost.

Whie I acknowledge this is unlikely to affect many people, I've hit this a few times when taking some screenshots for documentation purposes. It's fairly annoying.

I think it happens when the page switched from one responsive layout to another. For example, when the project sub-menu hops from the left side of the screen to the top of the screen.

Dear Sir,

request you to make setup of IBM cluster - two mode ( one cluster for DEV and another for UAT ) then request to install any EAR ( not WAR) record then replication/substitute for UAT fully scripted way using python/Jython. -

Regards
Anis

Currently Push Build Information API and command line ignores values set on WorkItems field, only to auto populate with values once one of the Integration extension is enabled.

Please allow Push Build Information API and Command line to
- Set WorkItems with values set on request
- Do not override values even if Issue Tracker extension is enabled

I would expect there to be a place in setup where I could enter my local time zone. Then subsequently all dates/times would display in my current time zone. This would include dashboard dates/times as well as Release Versioning.

When our Azure DevOps build runs it does a deployment to our Dev environment and specifies step names to skip with the Octopus CLI and the --skip argument. However there is nothing stopping someone from renaming the step in the Octopus process which then means we're no longer skipping the step. I would prefer that the Octopus CLI fail when doing a deployment with a --skip step name that does not exist in the process.

Hi it would be useful to have execute scripts feature on Octopus for data config changes to be picked from jira.
This will help to select dev env and validate SQL and use as test evidence to run on prod env.
Auditing abilities on octopus can be further enhanced by attaching script execution to Jira also. All major releases have database changes along with binary deployments, it is imperative we keep audit history for data changes also.

We have hundreds of projects in dozens of project groups in Octopus. As a DevOps engineer I have occasion to work with many projects over the whole system.

The filter by project and project groups are helpful. But what would really be helpful is the ability to go into a project - hit a * to make it a favorite, then on the dashboard tab have a drop down list of all my favorites that would take me directly to those projects.

For Tentacle deployment targets on Linux, you make RPMs clearly available: https://octopus.com/docs/infrastructure/deployment-targets/linux/tentacle

However, for SSH deployment targets on Linux, there is no RPM (or apt, etc...) for the Calamai package. Most Linux admins (rightfully) like to manage deployment targets with Puppet profiles, or similar, and the idea of manually installing Calamari directly on the servers creates configuration drift, and goes against most devops principles.

Could you make binary packages available for Calamari like you do for Tentacle?