1458 results found
-
Allow override of appVersion during Helm upgrade step
appVersion for Helm charts cannot be overridden with command-line arguments, which means the new version must be overridden before packaging the chart, which causes a new chart version per application version.
There are workarounds for this, but those cannot be done with the current Helm upgrade step.1 vote -
1 vote
-
Add Support for More Runbook Triggers
The only Runbook trigger right now is a scheduled trigger.
I would like to suggest two more trigger types:
Helm Chart Package Trigger:
When a new Helm Chart version of a package is published, then the trigger would fire. (Allowing the calling of a Runbook.)
Version Control Trigger:
If Octopus Deploy added a VCS trigger, then it would allow us to use GitOps.
Both of these allow Operations to enable control from check in / merge point in source control.
1 vote -
Execute F# script steps using dotnet fsi
Several packages are now incompatible with FSI as it uses the old execution engine, one example is FSharp.Data and latest Newtonsoft.Json. System.Text.Json is also out of the question, basically anything targeting Netstandard 2.0.
Switching to
dotnet fsiwill allow usage of said packages. It will also ensure cross platform compatibility for scripts and allows referencing packages in the script. https://devblogs.microsoft.com/dotnet/f-5-and-f-tools-update-for-june/5 votes -
Recognise when a variable is used for a feed ID or package version.
When using a variable to specify a package feed, or selecting package versions for a release, after creating a release Octopus displays an error on the release page.
With regard to the feed ID, it is possible to set a feed ID from variables as discussed here - https://octopus.com/docs/deployments/packages/dynamically-selecting-packages
With regard to versions, it is possible to set a version from variables, allowing the version of a package to by dynamically updated. This is most useful on occasions where another Octopus deployment is triggered as part of the process.
However, even though both scenarios works, after a release is created…
2 votes -
Support for NodeJS as scripts
Right now supported is Powershell, Bash, C#, F# and Python
Would be nice to be able to write nodejs scripts as well
1 vote -
Allow for metadata on internal packages
We want to be able to add custom values like commit id for example on packages
This would help knowing which commit id the package comes from, at the moment we are adding commit id in our release notes, but that ties to the release and not necessarily to the package
1 vote -
Support for .env files with Structured Variables
We are currently using React, Gatsby and Parcel which all use .env files for their environment variables
https://www.npmjs.com/package/dotenv
Currently .env files are not being recognized, they are assuming they are yaml files, which they are not, they are read similar to java properties as key values
Right now we have to use variable substitution, but would like to use structured so we don't need to add #{} tags in our code
1 vote -
Subscriptions - Multiple Headers
It would be great to add multiple headers in octopus subscription payload requests. Atm, it looks to be limited to just one.
Thanks to this, it would be possible to better control the logic through the application that rewrites/parse the payload and send to a specific webhook
2 votes -
add a changelog link to the "New Release" notification
Currently the "New Release" notification pop-up only contains the new release version number and a download link.
It would be infinitely more helpful if there were also a link to the changelog page.
The link cloud be generated from the current version of the octopus server along with the latest release version to show the user the changes that will be included in this new release of Octopus.Thanks!
1 vote -
Variable value scoped to release version
Often times I need to update a configuration variable but, only once we are about to release a particular release.
For example, if I'm upgrading my SQL server and moving to a new machine. I've got a release for the new SQL server version let's call it 2.0.0.0, however, I can't put my new connection string variable into Octopus configuration because I'm still deploying version 1 releases until it's time to migrate.
What I would like to be able to do is specify that the variable for the connection string is X for all releases prior to v 2.0.0.0 and…
2 votes -
Add First Class Support for Blue Green Deployments
For a product that is all about deployments, not having first class support for Blue Green deployments is.... odd.
Not a lot is needed. In fact you can't put in too much or it will be too opinionated.
Basically, all that is needed is something similar to your "tenant" system with a blue and a green line. But also show on the line which one is currently in use.
The "in use" flag will need a bit of effort as it can be a percentage or a list of users or both. But that is not too difficult to show.
…
1 vote -
Remove the need for a server level LOGIN in the SQL Server database
To manage LOGIN objects you need administrator access on the server level, database USER objects only needs access to the database level.
The setup wizard fails when started with an existing database if the provided credentials are not for a LOGIN object, after some initial cleanup tasks have succeeded.
1 vote -
Fuzzy Variable Matching
Allow replacements to be made over different files which share the same structure, but at a higher level requires a fuzzy match.
This would allow us to have a singular variable for repeated applications and the change would be applied to all json files that share the same structure.
Please see the support question below for more specific details.
1 vote -
Bindable variables for certificates in the kubernetes deploy container step
https://help.octopus.com/t/kubernetes-certificate-variable-binding/26581
In the kubernetes deploy step for the certificate field I have a need to use my own single text box bindable template variable rather than the current selection of certificate type only variables. The reason being that this cannot be scoped across both tenants and environments.
1 vote -
Include an environment variable or another method to set the server url for the docker images
At the moment there is no way to set the server url without going into configuration -> nodes in the GUI. For Ingress this is required to be first set up before requests are directed to the URL. It would be good to have the variable or some way to do this before container start without accessing the GUI. See: https://help.octopus.com/t/server-url-env-variable-for-docker/26543/2
1 vote -
Add link/URI within the Octopus, deployment output to support one-click access from CI/CD tools
If you use an Octopus, build/pipeline task within Azure DevOps Server/Services (or another CI/CD tool) to trigger a deployment, it would be useful to have a URI within the feedback output by the deployment within the Azure DevOps (or other CI/CD tool) build/pipeline.
This would allow the Octopus deployment to be accessed via a single click of that URI (as opposed to having to navigate back into Octopus and find the project, the release and then the deployment).
1 vote -
Deployment Time Option
If you redeploy to Tenant and that tenant is deemed to have the latest version, then the tenant is skipped.
Though the main reason (well for us and many other companies I've worked at using Octopus) is that we simply want to re-apply an updated variable set.
In this scenario:
* I don't want to redeploy the package.
* I only want to re-run the web.config/appsetting.json transforms.Install of just the skip option
(x) Skip deploy...
( ) Apply configuration changes only1 vote -
Add filter for the dashboard for failed deployments
We have a continually growing set of projects and some times I want to look through to see if any have failed so I can head off any issues before they become blocking for a team
I would loke to be able to set a quick filter on that dashboard to only see projects with a failed deployment. It could be a simple as a checkbox or toggle button1 vote -
Allow runbooks to be configured not to run immediately after a missed scheduled trigger
Runbooks can use triggers to start on schedule. If the OctopusDeploy service stops for any reason, a runbook that has missed its schedule will run as soon as OctopusDeploy become available. This is suboptimal where the missed trigger was powering off some VMs overnight and runs during your core hours, for example. This behavior should be configurable, much like the "Run task as soon as possible after a scheduled start is missed" setting in Windows scheduled tasks.
1 vote