This would be like runbook specific variables, but they are defined on the runbook and don't make sense to be in the published snapshot. They would generally be prompted values, but that shouldn't be required. They would be "snapshotted" when you run the runbook. When you are scheduling runbooks with a trigger, you should be able to provide values to use when the runbook is triggered.

For an example use of these, we have a Runbook that exports data from a database to a CSV and emails it. We have variables for the from and to dates and the email addresses to send to. These are variables that are specific to this runbook and have no meaning outside of this runbook, so polute the variable page.

I use Runbooks to check things in my Kubernetes cluster. I can run these on a trigger, but I have no way to surface them if there is a problem.

It would be really useful if Octopus Deploy had a dashboard that had configurable "Widgets" (or some such thing). You could have several different kinds of "Widgets", but the simplest would be one that has two states, "Needs Attention" or "Fine" (along with some text for context).

So I could define one of these Widgets, lets call it Container Base Image Status (a real example for me). In that widget I would have two statuses, one that says everything is fine, and one that says this needs attention.

When my Runbook runs on its trigger, it could set the status of that widget (for the Env that it ran in) to either "Needs Attention" or "Fine", along with some text for context.

This would allow me to use Runbooks as a way to keep track of the status of my environments rather than forcing me to go manually run the Status Runbooks (or look through Task history from triggered Runbooks.)

Tentacle retention policy is executed once all deployments steps are completed. When the retention policy step starts running, it blocks any other step.
This behavior is by design and can't be configured.

This design can cause issues if for some reason the retention policy step encounters issues and takes a long time to complete.

As a workaround we can add a deployment step of a dummy package at the end of the deployment process. As result the tentacle retention is executed at the last step of the deployment.

I would like to have an option to control when the retention policy step is executed where the options should be:
* Let Tentacle decide
* At the end of the deployment process

There are currently 2 package download options when deploying a release: using the package from the cache and always re-downloading. Both of these are useful, but each has one big downside that I think this feature would correct.

When using the package cache, Octopus will never pick up changes that were made to the same version of the package. If forcing a re-download, the package cache can quickly fill up, especially with multiple development teams (and yes, we have retention policies configured -- our packages are unfortunately quite large).

A new option that will just always re-download and keep a single package in the cache would address these issues. I am trying to solve a problem we are encountering when deploying packages from feature branches. We want to be able to have a single release (and therefore package version) per feature branch instead of having to create a new package version (and therefore release) for each new build.

Right now we are forced to re-download for every deployment, but this is quickly filling up our package cache. We could add more disk space, but at the same time, we don't care about having older versions of the package -- we don't even want to keep these packages around. For feature branches we only care about deploying the absolute latest version.

For a product that is all about deployments, not having first class support for Blue Green deployments is.... odd.

Not a lot is needed. In fact you can't put in too much or it will be too opinionated.

Basically, all that is needed is something similar to your "tenant" system with a blue and a green line. But also show on the line which one is currently in use.

The "in use" flag will need a bit of effort as it can be a percentage or a list of users or both. But that is not too difficult to show.

The "in use" can be something that is set by deployment steps. It should allow a list of users (not required to be Octopus users) and also allow a percentage. Note that even though it is set in the step, it does not actually do anything to the deployed environment. (That can be a feature of a later revision.) Just having the UI and the Variable makes it so that it can be wired up to Octopus such that Ops Teams can see it an control it.

These are just my ideas, but it is weird that a tool that is all about deployments makes us coble blue green deployments together with tenants and a bunch of scripts.