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.

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.

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

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