As of version 3.7.12 it is possible to use the "Transfer package" step and use the selected package on custom steps (e.g. push it to an s3 bucket).

However, when it comes to docker "packages" the only way to select a docker feed is by using one of the 3 default docker steps.

It would be nice to have a basic step which would allow us to select only the docker feed and have that step export the image+version (tag) to other steps.

In my case, this would allow me control the deployment of a specific image using custom templates (e.g. updating an AWS ECS service).

We have a pretty ephemeral environment in AWS and setup new environments several times a week. Our ELB healthchecks are tied to the web apps we're deploying. This can kind of create a timing or chicken-and-egg problem when we need to deploy a project to a new environment. We have to deploy the app for that box before the ELB kills the instance as unhealthy.

What I'd like to be able to do is deploy a project to an environment then as new EC2 instances are registered with Octopus we lean on deployment triggers to deploy the software as soon as the box is available. We can't do that now because you can't deploy a project to an environment until there's at least one healthy registered node in that environment.

This is similar, but not quite the same, as this request: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/11104227-allow-deployments-to-target-roles-that-don-t-exist

It would be really helpful if I could target a set of tenant machines in the script console.

Sometimes I want to run a script on the machines allocated to a specific tenant, but right now I need to pick those machines manually. That's OK if all my tenanted machines are named using a convention including the tenant name, but with the public cloud that often isn't the case.

What would be lovely is if I could choose one or more tenants and have the script console run the script across all the machines those tenants are allocated to.

Likewise it would be nice if this could extend to tenant tags using the same logic: find the list of tenants matching this tag query, and then run the script against all machines allocated to those tenants.

Source (private link): https://secure.helpscout.net/conversation/347634339/0/

The new 3.4 Multi-tenancy feature is great. But there is a limitation preventing it for some to use it effectively.

We have several projects, some have multi-tenant deployments (per client) some others not (tool project, shared services projects etc).

We deploy all these projects to the same test and staging servers and some as well to production environment. Meaning, the same machine might be used for multi-tenant and non-tenant deployments.

The current 3.4 release does not allow us to use the same environment/target for both type of projects.

Workaround as published (setup dummy tenant instance) is a less desirable, as we would need to reconfigure too many projects to use the dummy-tenant; Next to that it also sort of makes history and promotion of releases over environments less nice (redo releases using this dummy-instance just to be able to promote the correct instance up.

Workaround is definitely possible, but a nice fix (just allow mixed types of tenant-non-tenant projects to the same environment by configuration is preferable.

As part of my TeamCity builds I like to check if a build that ran a deployment has passed/failed (because sometimes a deployment has suceeded but tests run afterwards in TeamCity have failed), and if it has failed then raise a defect via the Octopus API. I like to add the name and link to the build in the defect description.

However, the the max length of the defect description box shortens the message posted. It would be great to see this increased.

Furthermore, if links could be supported somehow then users could click on the link to take them directly back to TeamCity.