I'd like to assign a manual intervention, or "Approval gate", at the environment level, independent of project.

We have many projects that can be deployed to our environments. The lifecycles these projects can deploy to have a mix of Dev, CI, Test and Production environments. Some important environments require approval before anything can be deployed to them (e.g. QA, PreProd, Production).

At the moment I have to add manual intervention steps to every project that could be deployed to those environments. I also have to make the intervention steps are conditional based on the environments they're going to (i.e. I don't want the intervention to trigger when going to dev environments). This leads to a great deal of maintenance to protect these environments, and if I make a mistake is doesn't "fail safe". I.e. if I mess up the logic, or miss a project, it will skip manual intervention and allow the project to be deployed.

My ideal feature would be to put a manual intervention, or Approval Gate, on an environment, so no matter what project is to be deployed to that environment, I can rest assured it can't succeed without prior approval.

Currently, when creating an Ingress Host Rule, you can only specify the "Path" and the "Service port". The Service Name appears to be calculated for you. Why not let the user specify the name?

One use case where providing the Service Name is critical is when using Ingress Annotations for the AWS ALB Ingress. An action annotation can be provided on the Ingress to tell the ALB Ingress Controller to create a specific action on the ALB. For example, an SSL redirect action. The annotation must be named "alb.ingress.kubernetes.io/actions.my-custom-action-name". Then in the host rule you specify the desired path (for SSL redirect it's just "/*), and then the Service Name must match the "my-custom-action-name" and Service Port must be "use-annotation".

Here is a complete example of creating such an SSL redirect action. https://kubernetes-sigs.github.io/aws-alb-ingress-controller/guide/tasks/ssl_redirect/

The work-around I employed was to set my custom action name to be the same as what is generated (which seems to just be whatever the Ingress Name itself is set to. However, this work around makes it so only one custom action can be annotated on the ingress.

It seems like a very small change: Allow user-defined Service Name property on Ingress Host Rule. Hopefully it is :)

TIA

Whenever there is a change in the variable after the creation of the release, we used to get warning saying "Release Snapshot has been changed". But we do have only one option to update the entire release without knowing what has been changed. It would be great if you have any way to find/highlight the variables and their values that will be updated when I click "Update Variables" in the release Snapshot section. It will minimize the risk when it's comes to updating the snapshots for production deployment and it will give a transparent view of what changes are done in the variables post release creation.

We're using various steps for deployment ('Deploy a package', 'Deploy to IIS') which both have variable substitution options to substitute variables in Web.config/App.config.

During deployment, i've noticed that these substitutions are logged. However, sometimes i see that our sensitive variables are being logged here at 'verbose' level. Other sensitive (and also non-sensitive) variables are obfuscated.

It seems that the deployment process decides by itself based on the name of the variable. In my opinion, the sensitive option of the variabel should be considered here as well.

An example of what we've got currently:
We've got an appsetting in our app.config, lets call it ConfigSetting
In octopus i've defined two variables, ConfigSetting (non-sensitive) and ConfigSettingSecret (sensitive). The secret is retrieved as output of a previous step.

Values are:
ConfigSetting = {Setting1:Value1,Setting2:Value2,Secret:#{ConfigSettingSecret}}
ConfigSettingSecret = #{Octopus.Action[GetSecret].Output}

Now, i've noticed that the ConfigSetting along with the actual secret is logged on variable substitution. Obviously, this should not be logged.

My feature request is therefore to prevent these sensitive variables from being logged.

Exclude process steps when you are creating release not before deploying release. Why?

We have multiple projects and when we are deploying to higher environments we are actually deploying "wrapper project" which contains releases of projects.

In each release, we don't always deploy all the projects so we want to exclude them from deploying.

We know that we can set up "deploy only if the version is greater". But If we exclude some of deploy release steps then we have a better overview of what actually has been deployed.

We just want to skip boring manually clicking each time before deployment to all environments. Also if the deployment fails you need to do it again...

So would be nice when you create release that includes this excluded steps into a snapshot of the release.