This is a huge issue with octopus. Needing to create a script to access published artifacts is so messy. Azure DevOps allows for immediate access to artifacts.

In parallel with this request, we need the ability to publish artifacts with a specific name instead of a randomized name given by Octopus. How are we supposed to clearly use a published artifact if it's given the name "Artifacts-#" ?

Can we please have support for the DNS-01 challenge type for LetsEncrypt. We don’t want to have to expose a server to the open internet just to validate a certificate domain. DNS-01 solves this by querying the DNS provider directly for the challeng token to ensure you own the domain in question.

Currently .war files are not supported by the Azure Web App deployment, it would be ideal that we can deploy this type of file directly to Azure Web Apps without having to take additional steps.

The system variable Octopus.Deployment.Created is updated/changes between deployment to the different environments, but it would be great to have a static value for when the Release itself was created.
So i suggest a new system variable Octopus.Release.Created that says when the release was created (with the Create Release button).

Need to be able to save and recall defined sets of environments used for different purposes. For example, In-House vs Out-of-House.

I have build agents with the .NET Core 3.0 SDK installed. I am unable to install the CLI as a dotnet tool, as the CLI will only run on .NET Core 2.X. I'd prefer not to have a separate container with the .NET Core 2.1+ runtime or SDK in order to use the CLI.

Currently there are several AWS deployment templates like one for uploading file to S3 bucket and few for deploying CloudFormation stacks.
The problem with them is that they have a short support of different features we have for traditional IIS or Azure templates. So the suggestion is to add some of these features to AWS templates too e.g

• JSON Configuration Variables,


• Custom Deployment Scripts,


• Configuration Variables,


• Configuration Transforms

Hi,
I have a service/container and I want to launch it in the same machine a number of times (variable to be applied per environment/tenant) .

Do you have something for this? Can you put this?

At present, all API keys for a user (service account user or 'real' user) do not have an expiry date.

As a result, non-required API keys can potentially leave access open via this key.

The suggestion would be to:
- allow users to specify the duration of the API key/token
- allow admins to specify the possible durations available to users/roles (e.g. administraters can stop users selecting 'unlimited' duration, and only allow 30, 60 or 90 days, for example)

When setting up a project for the first time, I manually copy and paste variables from config files (appSettings and connectionStrings) and it would be useful if I could have them imported and set to the value from the config during setup or on first deployment to QA / first environment. Given a large number of variables, this will be where most time is spent during project setup.

For example, allow us to add 1 hour to the time generated by 'DateNowUtc' or 'DateNow'.

In my case, I want to pass in an expiry time when generating a SAS token in an ARM template, but it's inconvenient to have to use PowerShell to generate that expiry time and then set an output variable.

The header here
https://octopus.com/docs/administration/data/octopus-database#Octopusdatabase-highavailability
is missing an "i" between "bil" and "ty". Says Availabilty and not Availability

I have multiple nuget packages that I want to deploy to a single location (these nuget packages all make up the single Application), can this be done with Octopus Deploy?

We would like to include build information (commits) from GitLab into our packages so that we can automate the release notes creation from packages.

The https://octopus.com/docs/packaging-applications/build-servers#build-information page states that "The recommended way to supply the build information is to add the Build Information step" but there is no GitLab step.

I would like to be able to manage variables in variable sets from both the variable set page and from the project level, when there are cases where I have included a variable set in my project. This will help reduce the back and forth navigation that is needed to make the necessary edits when I find I need to modify the variables that are in the set as I am maintaining my project.

Cloning steps is a nice and welcome addition. Can we expand it to a Process level and have Clone All Steps to a different project?

Currently, Variable Conditionals as documented here:
https://octopus.com/docs/deployment-process/variables/variable-substitutions#VariableSubstitutionSyntax-Conditionalsconditionals

Does not allow for evaluation of more than one condition, which makes the syntax really ugly and dificult to read when workaround/hacks are implemented to evaluate more than one condition...

For example, currently only this is allowed:

{if Octopus.Deployment.Tenant.Name == "PreProd"}prod#{else}uat#{/if}

Make is easy to do OR/AND and evaluate more than one condition, like this for example:

{if Octopus.Deployment.Tenant.Name == "PreProd" || Octopus.Deployment.Tenant.Name == "Production"}prod#{else}uat#{/if}

To get an idea of the issues review this post (describes workaround for AND but OR is not possible so far!):

https://help.octopus.com/t/run-condition-variables-two-conditions/1585