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.

Packer is a versatile tool, especially when working in a multi-cloud environment. It can be used for both creating both base gold images that can then be fully built on later or fully built imputable images.

I see an octopus step being able to be used to:
1) create or pull (from a repository) & update a json template with variables & transformation.
2) next packer validate
3) packer builds the image.

ideally, there would also be an "Octopus" provisioner for packer that would allow the download of repos, call templates, transforms, variables install tenticle via cli

but even it only did the first three you could still use existing PowerShell & bash scripting

The resulting image details ( from packer manifest provisioner) could then be returned to octopus as variables to be used in other process tasks such as launch an instance that octopus would then manage.

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.

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

Hello!

While working with variables in octopus I thought it would nice to “group” variables so that it’s easier to navigate. This would allow someone to organise and reason about the variables easier.

Anyways, here goes:

A.B.C[Foo] = 42
A.B.C[Bar] = 3.14
A.B.C[Foobar] = 256
The above naming of variables would imply that they are related in some way. Therefore it would be nice if the UI could display them as such

A.B.C[]
Foo = 42
Bar = 3.14
Foobar = 256
Obviously this is fairly arbitrary in the use of the [] but I think the idea is clear enough - have the UI group them together, even if in scripts etc they appear as flat key-value pairs. I think the ideal for me would be the ability to choose two or more variables to group together based on a pattern like A.B.C[#{element}] or A.B.#{element}.

p.s. nesting another grouping level underneath the initial grouping can be considered out of scope of this request. I don’t think I could come up with a clean UI design for that haha…