When creating an Octopus AWS Account (https://octopus.com/docs/infrastructure/deployment-targets/aws) you currently need to enter an AWS Access Key and Secret Key. This means the corresponding AWS Access Key needs to be periodically rotated, creating some management overhead and potential security vulnerabilities. Rather than an AWS Access Key and Secret Key, if we were able to enter an AWS IAM Role that is assumed whenever that Octopus AWS Account is used, then we would no longer need to manage AWS Access Keys.

In the background, Octopus Deploy would need to set it up so that the AWS IAM Role is assumed and temporary credentials (https://docs.aws.amazon.com/IAM/latest/UserGuide/idcredentialstemp_use-resources.html) are created whenever the corresponding Octopus AWS Account is used by a deploy process.

As for the credentials that are used to assume the AWS IAM Role, I would expect that the AWS service role for EC2 instances running the Octopus Deploy server / workers is used by default to assume the AWS IAM Role. And if Octopus is not running on EC2 instances, maybe as part of the creation of the Octopus AWS Account, when specifying the AWS IAM Role to assume, you could specify another Octopus AWS Account to use to assume that role. That way you could maintain a single AWS IAM User and Access Key, and then that user would be used to assume the AWS IAM Roles.

As an example, you could setup the Octopus Deploy server / workers EC2 role (or an IAM user) policy as follows:
Name: octopus-deploy-server
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50

Then when creating the AWS IAM Role that will be assumed as part of the deployment you would:
1. Setup the Trust Relationship as:
Name: octopus-deploy-my-project-deployer
https://gist.github.com/burck1/5469acbff31b71fa69ef8d91c4426e50
2. Setup the AWS IAM Role policy to have access to whatever AWS resources needed.

Note: This feature would also allow cross-account access as AWS IAM Roles can be assumed within other accounts.

It would be great if the Octopus dashboard, which displays the current releases of each application in each environment, contained links to the applications in the specific environments. E.g. if the box displaying details of the most recent deployment of Application X to Environment Y also contained a link to that app in that environment

We presently maintain this info outside of Octopus, in Wiki pages etc, but it’s a pain to maintain.
It would be great if this was directly available in Octopus, because the matrix of applications to environments is already there. Forcing users to access the links via Octopus would also have the advantage of making sure they know the version they are accessing too (we do display the version numbers in our apps also, but you know what I mean).

Was thinking if “Application URL” was a property of a deployment, and there was some means of setting that property as part of the deployment process steps (say via a step type), then the dashboard could check if the URL for deployments had been set, and if so display a link. Also has the benefit that if the URL needs to change with a given release, that can be controlled like other changes

I think a lot of customers would find this a useful feature… there is nothing special about our situation, maybe just that we have a lot of environments and a lot of apps, making the problem more important to solve

It would be useful if we could set variables in a variable set to a Project Group scope.

The use case for this is that we have a shared variable set that sets a product ID.

We could then scope this by product group.

eg

Variable Set Products
Product Id - ATeam Scoped to Project Group A
Product Id - BTeam Scoped to Project Group B

Project Group A
- Proj A1
- Proj A2

Project Group B
- Proj B1
- Proj B2

Currently we have to override the ProductID in every project in Project Group B which sometimes gets overlooked, scoping by Project Group would remove the need to do this.

Add variables to Runbooks, so that adding new variables to the project for a specific Runbook don't cause the snapshots of other Runbooks to be old.

For example, 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. The from/to dates are prompted variables, so you can do an adhoc run. If no dates are provided, it will default to the last week of data.

These variables only have meaning for this Runbook, so it would be nice to define them for the Runbook.

I find that the most common task performed on tenants is modification of tenant variables. However, I feel that the UI does not support this task very well.

I find that once I click through on the tenant, my next step is to click on the project in which I wish to set variables for which does not result in the expected action (it takes you to the project instead).

My recommendation is that the tenant variables becomes the landing page for tenants and the project administration for the tenant could become a secondary page (or perhaps it could even be combined into the variables page).

With standard octopus deployment there is a "deploy a release" step which can be used to run other projects from a parent project.

It would be usefult o have a similar "run a runbook" step to be able to build up run books from smaller steps into bigger processes.

Our use case is swithcing to DR, there are numerous steps such as stopping various services, starting other services, stopping replication etc. But, each of these steps is also useful in itself so we have steps effectively duplicated, once in the invoke dr runbook and once in a runbook all by their lonesome. But, the data and process is identical across them all.

When I have a few Parent processes with some Child process in them, The Process Editor is very hard to use. You get that dreaded "Menu Options unavailable while viewing a parent or its child steps." Comment box appear. The problem is that there is no other way to do Parent tasks like add a child step now that you have a "parent or its child steps" selected. Only when you click into another Parent step can you access the Parent process menu. This is hugely frustrating when you are working of creating a bunch of child steps.

Please change this so that you can at least access the Parent Menu when Viewing a Parent step. Currently you can only see 'Delete' in that menu. I'm not sure why you have made this so it can't access Menu Options while viewing a parent or its child steps. But The best result here would be to revisit this decision.

The OctoPack project is great for Framework projects. We add the nuget dependency to select projects and add /p:RunOctoPack=true to our build script. The build script does not need to be updated for every new, removed or renamed octo-packed project.

SDK projects are less automated. After building, we have to run dotnet publish, then octo pack for each project. It would be great to define 1 build script, then update the projects as needed to pack or not.

Idea to attain goal:

1. Add element <IsOctoPackable>true</IsOctoPackable> in csproj that works similar to IsPackable.




2. Allow dot net octo pack to point to the csproj, multiple csproj, or the sln. Perform actions on any projects with IsOctoPack==true.




3. Add option --no-publish (following --nobuild and --no-restore convention)




4. Call dotnet publish (unless --no-publish was specified), passing on applicable parameters




5. Derive basePath from output/{projectName} folder (publish will create a directory with the project name in the --output folder).




6. Derive id from OctoPackageId (new csproj property), AssemblyName, or Project Name (AssemblyName is project name if missing).