A thought just occurred to me. Being able to pause for manual intervention after every step could be an option in the advanced settings of a deployment or runbook execution. This would assist in testing runbooks/deployment processes meaning you can check state at each stage. Maybe not a manual intervention, perhaps just a "next step" or "proceed" button or similar.

in order to determine if a worker can safely be terminated it would be good to have a rest api for this. The closest thing we get today is this script https://github.com/OctopusDeploy/OctopusDeploy-Api/blob/master/REST/PowerShell/Workers/GetWorkersUsedInTasks.ps1 which uses string matching in task log output - very rudimentary, and with tons of failure modes.

I know there's a "worker lease" table, a rest api endpoint covering that table would be great.

It would be nice if we could install our octopus instances as a PWA and integrate desktop notifications for things like deployment events, failures, and possibly manual steps needing approval

Provide ability to reorder target environments in a lifecycle, just like you can reorder steps in a process. Currently, we have to delete all subsequent environments when adding a new environment, then re-add all those deleted environments. Being able to simply reorder these in the UI seems a quick win.

We were recently audited, and asked to provide screenshots showing which users had "DeploymentCreate" permissions.

please add a new Permissions Audit screen that allows selecting one or more permissions and spaces, and then showing all users who have that permission.

I would assume* it's mostly a case of adding linux-arm64 as a runtime argument.

Octopus is the /only/ thing that's preventing me from moving my TeamCity agents to Amazon t4g instances. I can accept that the plugin for TC maybe more involved but can we atleast get a build of the cli supporting ARM so that I can manually post manually to Octopus.

Octopus-API/Octopus-Client works on Project Id or SlugId, However, there is no way to see these values in the web app. It would be intuitive if they are included in the project settings (albeit read-only) for usage across Octopus tools.

Usage:
https://help.octopus.com/t/can-we-see-the-project-id-in-octopus-web-app

when I choose “Create Release” and the lifecycle only runs in one place, the Save button should tell you it’s going to go ahead and run.

idk what you call this icon with the orange square and white lightning bolt

but when the lifecycle is in this state, the save button really means, “go ahead and run”.

When running a deployment and showing its status, specially on longer deployments, the TeamCity agents will be on hold for the duration of the task. On deployments where guided interruption is enabled this is specially taxing on agent licenses.

Since 2020.2.4 TeamCity has introduced agentless builds, where an agent can be detached during the execution of a build, and requires the running process to call TC back via api and inform the build has finished.

This is currently not possible on the plugin and, using powershell, I've found hard to establish the whole deployment status at X point in time.

This would be useful for replacing values especially in the values-file from Chart Package or Additional Package. With this feature we don't need to have variable replacement syntax in our source-files.

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.

Currently the estimated completion time is displayed in the Octopus UI. If I'm understanding the response I got on the support forms correctly that value is calculated in the client and not pulled from the server. It would be really useful that that value was calculated on the server and the estimated completion time was exposed as an Octopus variable.
https://help.octopus.com/t/get-estimated-completion-time-programmatically/27375

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.

Add Deployments link to Worker View like what exists for deployment targets

Deployment target link path example: /app#/Spaces-1/infrastructure/machines/Machines-xxxx/deployments

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.

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

As a project leader I should be able to group variables on Octopus UI. This can be just logical separation.

This solve the problem with linked variables and help mange them.

For example It could collapse elements that are in structure - for example: db.username and db.password can be collapse as elements of root db or by labeling variables and then can be filtered by using specific label, for example - db.