Currently, the only way to set up AWS authentication for an ECR external feed, AWS deployment target, community library task, etc, is with an IAM user secret such as API access keypair. Our product secrutiy team has exlicitly forbidden use of secrets such as keypairs like this and requires everything to use IAM role authentication via role assumption.

It would be lovely to replace the access key and secret key inputs with a single input for an IAM role name to assume into in order to get the needed credentials. The authentication and login could then execute on workers with the proper node instance roles that allow for the needed role assumption.

All our workers in AWS are set up with proper roles that allow assumption into, e.g. ECR access role that can log in to ECR docker registry and browse the images. If executing from workers theres no need to supply credentials beyond the already-configured worker node IAM role.

Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

When deploying application containers, there can be times when you want a password that no human needs to know and survives only for the lifetime of the container.

Our primary use case is generating secure keystores for certificates, etc. At container start-up, it will generate a new local keystore and we then have the ability to dynamically sign CSRs generated within the container via an external signing service.

We do not want to leave the keystore nor the certificate objects without any password, but also do not want to store the values anywhere external to the container.

Granted, we certainly can do things like set a short certificate lifetime, adopt policies such rapid container cycling, etc. in addition as a layered approach, but I see no reason to externally persist secrets that are of no use and add operational overhead to cycle manually.

We've been trying to ensure that any 'Step Templates' created in Octopus contain scripts/code (PowerShell) that exists within a package. That package is then referenced as part of the 'Step Template'.

The problem we have with this is that as soon as the package is pushed, it then gets used in any new releases. This means that we have no opportunity to test this in Octopus prior to new releases in pipelines using it.

It would be useful if within the 'Step Template' we could specify/fix the package version (or specify a range) used so that all other pipeline releases would use the specified version (rather than the latest) ... similar to some of the functionality that can be done in Channels..

https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5748518-rather-than-allways-taking-the-latest-version-of

... and it would be useful if, within a project pipeline, when a user was setting up use of the 'Step Template' that they had an option to override the package version defined by the step template (unless there was a setting in the 'Step Template' denying the ability to override it).

This would mean we can push the new 'Step Template' code/scripts/packages as much as we want, but we don't have to use them until the 'Step Template' is explicitly updated to use them.

When creating a deployment 'parent' that utilizes the "Deploy A Release" step 'child', it's possible to create a 'parent' release with a 'child' release version that uses a different lifecycle. When attempting to deploy, the following cryptic error is returned:

The step failed: Activity <Child Step Name> on the Octopus Server failed with error 'The release has unresolved defects and cannot be deployed to this environment.
Once you have corrected these problems you can try again.
If the problem is related to a variable you will need to update the variables for this release or recreate the release for the changes to take effect.
If the problem is related to the deployment process you will need to create a new release for the changes to take effect.'.

When selecting a 'child' release version, only releases applicable to the same lifecycle should be displayed. The Latest column should display the latest release in the current lifecycle, and the Select Version popup should be filtered as well. Additionally, octo.exe deploy-release should pick the latest 'child' release in the current lifecycle.

Currently you can set a condition to a step so that it is only run on tenants with certain tenant tags.

If I know want to run one step on tenants with a tag but not run a second step with a the same tenant tag (different configuration for these tenants) I have to use conditions field instead. This gives a very unclear overview of the process as it appears to that both step run on tenants with the tag.

Ideal would be
* Step A run on tenants with Tag A.
* Step B run on all tenants except those with Tag A.

This would make it very clear and I can easily create a tag Special-Security-Config-Tenant and make it clear which steps run what. I can create a negative tag, but that will make me have to maintain that on all other tenants and remember to add them to it for every special tenant tag there is.

When you navigate to a project, you get to the Overview page as a start. When you open up many projects at once (cause a change triggered multiple CI for example, which should be deployed) all of them will show "Overview - Octopus Deploy" in the HTML title and as such it's also what's displayed on the browser tabs:

You loose the ability to distinguish between these tabs. It also means that if you bookmark multiple projects then you'll have to change their title manually to have a valuable label for them. You have to click around them to figure out which tab is which.

What I'm proposing here is to take a look at titles generally around the product and make them as short and describing as you can. Start with the projects if it's possible, as I think that's the most frequently used parts.

Few examples:

1.) Overview - Product.Vertical.ServiceType.ServiceName - Octopus Deploy
2.) Overview - Product.Vertical.ServiceType.ServiceName (The icon should be enough to identify that it's Octopus Deploy)