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.

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.

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

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.

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.

It would be great to add multiple headers in octopus subscription payload requests. Atm, it looks to be limited to just one.

Thanks to this, it would be possible to better control the logic through the application that rewrites/parse the payload and send to a specific webhook

At the moment there is no way to set the server url without going into configuration -> nodes in the GUI. For Ingress this is required to be first set up before requests are directed to the URL. It would be good to have the variable or some way to do this before container start without accessing the GUI. See: https://help.octopus.com/t/server-url-env-variable-for-docker/26543/2

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

If you use an Octopus, build/pipeline task within Azure DevOps Server/Services (or another CI/CD tool) to trigger a deployment, it would be useful to have a URI within the feedback output by the deployment within the Azure DevOps (or other CI/CD tool) build/pipeline.

This would allow the Octopus deployment to be accessed via a single click of that URI (as opposed to having to navigate back into Octopus and find the project, the release and then the deployment).

If you redeploy to Tenant and that tenant is deemed to have the latest version, then the tenant is skipped.

Though the main reason (well for us and many other companies I've worked at using Octopus) is that we simply want to re-apply an updated variable set.

In this scenario:
* I don't want to redeploy the package.
* I only want to re-run the web.config/appsetting.json transforms.

Install of just the skip option
(x) Skip deploy...
( ) Apply configuration changes only

Applying the retention policy at the end of a deployment isn’t the best use of deployment time especially in a tenanted environment with many packages to deploy for many tenants on a single vm.

I would love to see an option to apply the retention policy out of hours, when the environment is at a low usage.

It would certainly speed up our deployments.

Similar to, but using a schdule.
https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/42726191-control-when-tentacle-retention-policy-step-will-b

We have a continually growing set of projects and some times I want to look through to see if any have failed so I can head off any issues before they become blocking for a team
I would loke to be able to set a quick filter on that dashboard to only see projects with a failed deployment. It could be a simple as a checkbox or toggle button

Runbooks can use triggers to start on schedule. If the OctopusDeploy service stops for any reason, a runbook that has missed its schedule will run as soon as OctopusDeploy become available. This is suboptimal where the missed trigger was powering off some VMs overnight and runs during your core hours, for example. This behavior should be configurable, much like the "Run task as soon as possible after a scheduled start is missed" setting in Windows scheduled tasks.

When viewing a task log you offer 3 settings:
1. Expand
2. Log Level
3. Log tail

They default to Interesting, Info, Last 20

In my position, those settings are almost always unhelpful - I have to change the selections with every task log I view, and in my position I view a ton of them a day.

I'd like the option to set my own personal Task Log View default values so that when I click on a task log my preset selections are automatically loaded and the task log is in my preferred state on page load.

It would be great if octopus has a project wise dashboard option where we can create visualization of project build stability like status of last 100 deployments , how many passed , how many failed etc