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.

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)

Semver 2.0.0 support has been added to Octopus, now supporting both pre-release tags and build metadata, e.g.

2.0.0-pre.release+build.info

However Channel Version Range matching has not been expanded to also support SemVer 2.0.0, and still only allow matching on SemVer 1.0.0 components, the version number (range) and pre-release tag (regex).

I suggest you add SemVer 2.0.0 support to Channel Version Ranges, adding a second regex to optionally match on build info.

The will enable users to automatically select and restrict the correct deployment Channel for the type of build.

Use case 1: We have some projects that use opinionated frameworks that just love to bake in environment configurations as part of their build process. As a result we have some packages where the SemVer differs only by the build information, based the environment it was built for, e.g.

1.2.3+abcd123.europe
1.2.3+abcd123.useast

We would like to use Channel Version Rules to ensure the correct configuration uses the correct Channel only. And to enable the use of Automatic Release Creation.

Use case 2: We have Kubernetes clusters with both Linux and Windows nodes, building services requires different build configurations and dependencies, and so we have two configurations of each release that differ only by the build information.

1.2.3+win64
1.2.3+linux

Use case 3: We have nodejs serverless functions that we want to deploy across Lambda, Knative, Azure Functions. The same functions can be written to run in all three, but the build packaging needs to be different. As a result we have some packages where the SemVer differs only by the build information, based the environment it was built for, e.g.

1.2.3+lamda
1.2.3+azure
1.2.3+knative

In discussion it was suggested to append the build configuration information on the package name rather that to the SemVer. However that mixes two concerns into the one field, that isn't even part of the version. SerVer 2.0.0 introduces a way to do this properly, and Octopus should ideally support that best practice.

Ref: https://octopus.com/docs/deployment-process/channels#Channels-VersionRange
Ref: https://semver.org/#semantic-versioning-200
Ref: https://help.octopus.com/t/can-channel-version-rules-match-on-build-information/23370

I help manage deployments for a software team that is working on moving from bi-weekly releases to continuous delivery. In order to transition smoothly, we have decided to have four environments in our pipeline: Dev > Alpha > Beta > Production. This allows us to continuously deliver internally from Dev (automatically deployed to from build server) to Alpha (snapshot of all projects promoted to Beta bi-weekly for staging).

What I would like to have the ability to do is make all deployments to Dev synchronous in that they wait if there is a current deployment to Dev and stay pending if that deployment fails. I do not want this to happen on any other environments.

I will be using the Run a Script step template and the Octopus API to do this with proper scoping in each project’s process in the meantime, but a built in feature would save a lot of maintenance. I would also expect that this is a common requirement for continuous delivery in order to accurately freeze your pipeline.

We have nearly a dozen client/WPF projects that primarily consist of backing up a directory and then overwriting it with an updated package (size ranging from 20-350MB). Each of these projects push their packages to 20 remote servers, but the servers cannot host tentacles due to our security policies, so we run the steps from one of our Octopus hosts (via tentacle installed alongside the manager service). This is slow and expensive on the Octopus host, especially when there are many other deploys underway. Worst of all, it forces steps to deploy in serial versus parallel because all steps are running through a single agent.

After reading a bit on workers and worker pools, I thought they might provide a solution for our bottleneck by offloading the work from our Octo servers and enabling parallel deployments. However, after building a pool, I realized worker-enabled steps are seemingly limited to cloud and scripts. If I was pushing these packages to an S3 bucket, I’d be good to go, but I cannot choose a worker pool as the execution location for the ‘Deploy a Package’ steps we are using. I’ve also considered using PS scripts to push these packages around, but we enjoy using built in configuration features to uniquely configure each remote locations files.

Can worker pool support be enabled for the ‘Deploy a Package’ step so I can use workers to push packages to remote Windows servers?

Been setting up multiple pipelines for Azure Data Factory (ADF) resources, defined by a series of Json files and would like to to use the Json Configuration Variables for configuring these. In ADF you typically have a series of linked services json files, specifying e.g. connection strings, credentials, input type etc - all with the same hierarchy - E.g. the connection string would be specified as 'properties:typeProperties:connectionString' in all the linked service files - hence the problem, since all json files are applied with the same OD variables.

I proprose an extension to the existing Json Configuration Variables feature, where you can specify which file to scope the OD variable for - e.g. to scope the variable to the file ls_blob_storageaccount.json:
'ls_blob_storageaccount.json) -> configuration:typeConfiguration:connectionString'