General
-
Kubernetes Ingress doesn't allow to configure TLS
Allow kubernetes ingress to specify TLS configuration.
15 votesThis was implemented in 2018.11.2
https://github.com/OctopusDeploy/Issues/issues/4929 -
Allow defining an explicit order for prompted variables
At the moment (at least to my knowledge) the order in which prompted variables are shown is dependent on the variable name (ordered alphabetically).
It would be really cool if there was a possibility to give prompted variables an explicit order so that we can control in which order they appear in a simpler manner. For example it would be cool if one could just set a "priority" value for a prompted variable. This "priority" could be an integer and the prompts could then be ordered by this priority in descending order.
Unfortunately giving them names to achieve the correct…
13 votesPrompted variables are now shown in alphabetical order, as of 2019.7.2.
-
Allow kubernetes & helm steps to override the target provided namespace
Although the kubernetes target type defines its namespace, there may be some situations where a different namespace should be used for a given step
1 voteOverriding the namespace on the Helm step was implemented in 2019.1.1: https://github.com/OctopusDeploy/Issues/issues/5141
We can create a new suggestion for the other kubernetes steps if desired.
-
Show variable snapshot differences in release screen
Sometimes when deploying, the user receives this message:
"For consistency, this deployment will use a snapshot of the variables and deployment process that was taken when the release was created, which does not include the latest changes that have been made to the project. A changed process can only be incorporated by creating a new release (this one may be renamed if desired). Variables can be updated via the release page, clicking Show to show the variables from the snapshot, and clicking the Update variables button."
It would be great to be able to tell the user exactly what changed,…
217 votesIntegrated in https://github.com/OctopusDeploy/Issues/issues/4700
-
Allow cloning of tenants
It should be possible to clone a tenant including it's current configuration in a similar way to that you can clone whole projects.
Tenants tend to be similarly configured with only minor changes to each one so it would save time rather than having to configure each one from scratch.145 votesThe ability to clone tenants was delivered in Octopus 2019.8
-
Add Let's Encrypt automation to OD server
Ensuring certificates for the OD server are up to date are a little annoying. It would be awesome if the OD server could support renewing it's own hosting certificate with Let's Encrypt.
I've had a stab at creating custom steps to do this. The main issue is domain validation (DV). DNS validation often requires manual intervention and OD server controls http (see discussion at https://community.letsencrypt.org/t/domain-validation/26512 ).
The only way I see this really progressing forward is if OD server supports Let's Encrypt in the server as a maintanence task as it would be able to respond to http DV requests.…
16 votesThis has been released with Octopus 3.15. See our blog post for more information – https://octopus.com/blog/octopus-release-3-15.
-
Allow project dependencies - so deploying one project would automatically deploy all dependent projects
We have many dependencies between our projects. So for example we have cross database dependencies which mean that a particular version of the database must be installed prior to another version. Similarly we have base services that are required by all others that must be installed first. There is currently no way of telling Octopus that one project depends upon another.
We could create one great big Octopus deployment with all the steps in it to deploy the TFS projects/libraries in the correct order. But this would be very complicated because of the large number of dependencies.
It would be…
317 votesThis was shipped in Octopus version 2018.2: https://octopus.com/blog/deploy-release-step/deploy-release-step
-
Improve variables UI
The variables view is very basic and it generally needs improving since it quickly gets hard to use when you begin adding lots of variables.
- You have to add the same variable name for multiple environments and the ordering of environments is not the same. This is error prone and makes the list hard to parse.
- There is no description for variables so you need to add very long names sometimes. This has already been covered, but I added it for completeness. See https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6079578-enhance-the-variable-maintenance-screen-with-varia
- There can be different types of variables which are changed for different reasons. It would be…
991 votesThanks everyone for your suggestions. We are happy to announce that a new version of the Variable Editor has shipped in Octopus 4.0! See https://octopus.com/blog/octopus-release-4-0 for more details.
In this first release, we have focused on providing a great variable editing experience, which we hope you will love! Although we haven’t yet been able to implement all of your great suggestions, we have been able to build an extensible variable editor that we will continue to improve in future.
-
C# Script in script modules
We need to use C# code as script in the script modules
229 votesHappy to announce that this shipped in 2019.5.0!
-
Improve Add Step functionality
We are working on making the Add Step functionality much better. The idea is to show built-in steps, community step templates (from http://library.octopus.com/) and custom step templates in one central location. Please let us know what you think by leaving your comment below.
3 votesThis has been released as part of 3.7 (https://octofront.com/content/blog/octopus-deploy-3.7-effortless-step-templates)
-
Find variable usage across all projects and variable sets
When working with library variable sets used in many projects with many steps it is cumbersome to figure out where a given variable is used.
When updating a deployment process, certain tasks become very difficult, such as:
-Renaming or deleting a variable
-Checking validity of a newly-updated variable value across all usagesWith a "find all" feature these tasks would be much simpler (plus I'm sure there would be wider-reaching benefits).
343 votesHappy to announce we’ve added a usage tab to the variable set page in 2019.5.4, where you can view which projects and releases are using a variable set. While this does not cover all suggestions below, we are confident that this goes a long way to solving the problem.
Finding the usages of individual variables is something that is a lot more complex than it sounds, and we are unlikely to implement. Many variables usages are embedded in strings, or even in files sourced from packages, meaning any results we displayed would be incomplete.
If you think we’ve misinterpreted this suggestion, please raise a new suggestion with a bit more detail about the use case, and let us know in the comments below.
-
Automatic release creation to allow packages with variables in IDs
Currently the automatic release creation feature does not resolve variables when looking if a package is used in a project set for automatic release creation. You can only use package IDs with static names.
It would be great if you could use variables in the package ID and have them resolved when the package is pushed.
Source: http://help.octopusdeploy.com/discussions/problems/28069
217 votesThe support for package variables and Step Templates in Automatic Release Creation and Scheduled Triggers has been greatly improved in https://github.com/OctopusDeploy/Issues/issues/4236 It will ship as part of `2019.4.0`
-
Viewing variables for a release should evaluate nested variables
I regularly use nested variables to minimise the number of variable changes I must make between environments. Consider something like this:
data source=#{Database.Server};initial catalog=#{Database.Name};#{Database.Auth};
This allows me to just specify simple variables for the DB server, the DB name and the type of auth being used, without having to construct a connectionstring every time (and probably making the odd mistake).
It would be great if I could see the fully-evaluated variables when i click "Show variables" on a release - or at least have a switch between the raw variables and evaluated variables.
3 votesThis functionality was release in 2018.3
-
Add an option to only create a binding in IIS if it does not already exist
We would really like to have an option to leave bindings alone in IIS if they already exist.
I configure a single binding as a templated deployment step. I would like octopus to automatically create the IIS app and bindings in the event the app pool and website doesn't exist - but if it does already exist I'd prefer it not to reconfigure the bindings.
This is useful when we create website aliases for production environments which don't fit the normal QA and UAT environment setup (but they happen to use the same steps).
Best would be a checkbox:
"Overwrite…
148 votesThis will ship in `2019.5.11` and in the next LTS
-
Add support for Python scripting.
It would be great to see Python listed as a script step. Python is heavily utilized in the infrastructure space, AWS, F5, Citrix, VMware and will help to drive full automation further up the stack.
119 votesThis will ship in `2019.1.1` today
-
Compliance with latest SemVer
Would like that OD is in compliance with the latest version of SemVer, so that the Pre-Release flag, and Build Metadata can be utilized in the release number.
8 votesFull support for SemVer 2.0 has been provided from the Octopus Deploy 3.4.0 build.
-
Add ability to indicate whether Windows Service should be started on deployment
In some environments we do not want a Windows Service started after it is deployed. In the current Octopus.Features.WindowsService_BeforePostDeploy.ps1 file the service is always started. It would be great to have a flag that could prevent the service from being started.
159 votes -
Rather than allways taking the "latest" version of a package, can we scope the step to within a particular version range
When you create a release, Octopus default to picking up the latest version of the available packages.
We have multiple forks of our packages, and we need to be able to restrict a package step so that it is limited to a particular version range of the package, for example:-
If we have a major version 1 of a package on a step,
If we later create a fork and do work on a major version 2,
We do not want the next octopus release to pick up major version 2 - we want to limit the scope of the…
34 votesThis ability is available via the Channels feature as provided in Octopus Deploy 3.2 (http://docs.octopusdeploy.com/display/OD/Channels).
Channels can specify version rules that define what packages are included in that release. -
Allow me to choose which environments a project uses / per project environments
We have multiple projects being deployed to different servers in heterogeneous environments. Some are just test-production, others are dev-test-staging-production. The projects often have completely separate environments.
It would be beneficial to be able to either choose which environments a project can deploy to, or to be able to set up per-project environments to be able to keep the same names for config transforms. (ex. "Web.Test.cfg" instead of "Web.Test-Product1.cfg")
Currently the Dashboard is also very "cluttered" with empty boxes due to those environments not being in use for certain projects.
8 votesLifecycles are the way in which users can define what environments are used in what projects
https://octopus.com/docs/deploying-applications/deployment-process/projects/lifecycles -
Support semver 2.0 build metadata in the release version.
In our project we have 2 branches - trunk and patch - both of which produce packages for Octopus and use semantic versioning when creating the Octopus release in the build. I would like to specify a build from the patch branch explicitly so that when packaging off the trunk my release would be 1.24.102948 but when packaging off the patch branch my release would be 1.24.102949+patch. My workaround is to use the pre-release metadata so my patch builds are producing octopus releases 1.24.102949-patch.
29 votesThis feature has now been provided in Octopus Deploy 3.4.0 (https://octopus.com/downloads/3.4.0)
See the recent blog post covering these changes https://octopus.com/blog/semver2
- Don't see your idea?