Currently it it not possible to script additional actions when planning to apply or applying a Terraform template. This means that additional steps are required to carry out simple takes like importing an exiting resource before planning, or uploading a saved plan to S3 so that it can be pulled and applied.

Many other steps have this configurable feature, and I believe it would be highly effective here.

Suggestion -
- Pre-deployment script runs before 'terraform init' (allowing download of plan from S3, for example).
- Deployment script runs after 'terraform init' (allowing 'terraform import' after the template has been initialised, for example).
- Post-deployment script runs after 'terraform plan|apply' (allowing upload of plan to S3, for example).

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

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.)

I manage a multi tenant system and the dashboard is always a pain to use.

First the icon cant be trusted as it dose not accurately show things like a single tenant deploying (The animated icon).

But the real pain is that if I click that icon it takes me to the deployment page of one of the tenants. What I want it to do is take me to a screen for all of the tenants. Something like the tasks screen filtered by environment would be very nice.

Then I would be able to see the true state of all the tenants in this deployment and not just a random one.

And then i can click the necessary icon from that screen to get to the individual deployment details.

It would be nice to add some screen shots but it looks like there is no easy way to do that here any more. ):

It would be extremely useful to allow variables to be set as an environment variable before the process starts (and even allow outputs to be made environment variables). At the moment it is extremely hard to write generic scripts for both development and for use in octopus.

Allowing variables to be set as environment variables eliminates this issue as well as allows more providers etc.

If I take a terraform run where the provider (say digital ocean and terraform cloud) can be initialized via environment variables I do not need to litter my scripts with octopus only if conditionals. They then function exactly like they would on the dev machine.

This is pretty much blocking the team from moving to octopus because it is hard to debug and run efficiently and thus we are choosing to just use Teamcity for various steps.

Note: This also means im not limited to the built in 'Accounts' that are pretty useless when it can simply support everything.