I'm using Octopus Deploy inside a Kubernetes cluster, however I want to deploy to that cluster as well..

I'm using https://kubernetes.default.svc which is the local endpoint of Kubernetes, typically thats all thats needed as the pod running already has a built-in token used to access Kubernetes via /var/run/secrets/kubernetes.io/serviceaccount/token

https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/

However the UI is complaining "Authentication" is required, so unfortunately, I was required to create another token just to have access.

Can we allow authentication to be optional or an option to use a local cluster?

Now that we can store git credentials in the library, we would like to use those centrally stored credentials for GitHub Repo feed settings as well.

We're currently using Octopus to manage our Kubernetes clusters, but we're interested in transitioning to a GitOps Pull Model (rather than the current Push based approach where the Octopus Server is executing kubectl commands against our clusters) in which (in a similar fashion to the polling tentacles Octopus already offers), a service would run within our clusters and periodically
poll both git repositiories and docker registries/helm feeds for changes and sync the cluster state accordingly.

I'd like to see a pre-deployment preview of the contents of the package so that I know what the script path will be without having to guess the script path.

Use SCIM to provision groups for Teams integration between Azure AD and Octopus. I submit GitHub Enterprise Managed Users as an example.

Kubernetes likes to consume hashed values, e.g. for Ingress basic auth we need to provide a secret where the password is already hashed, e.g.: "admin:$apr1$QVF90yb6$JxGT0BWDpw0negAzDy3YT."

This forces us to have two variables: one for the password and the second for its hash

And that may become a problem in the future when we will update one and forget about another

In an ideal world will be so nice to just add something like #{Password | Bcrypt} as a value for a Kubernetes secret

Also, it is a good spot for other algorithms like Md5, Sha-X, ...

On the Deployments -> Overview page, instead of just an = operator when filtering by release, it would be very helpful to allow filtering by >= and <= operators. It would also by very helpful to filter just on major and minor release numbers as well or both independently.

Ex 1: filter by all tenants on major version X or greater
Ex 2: filter by all tenants on major version X and minor version Y or less (to find everyone impacted by a specific bug)

There should be a "table" view of tenants. Table columns should be customizable and and there should be the ability to filter. This way I can easily modify variables.

Lets say I have a variable indicating which web server my app is assigned to. And I get a new web server. I could look at this table, sort or filter on the web_server variable and assign tenants/apps to the new webserver.

I have a prompted variable to ask the deployer to enter a ticket number. If they enter anything other than a number my automation breaks. So I would like to restrict the user input to being only a number.

The ability to use variables exists in so many different places when setting up Kubernetes deployments, but one place I would think would make the most sense is the container image name.

When creating step templates, I found this one field a barrier from allowing me to use the templates because we use that image name for checking logs for various debugging.

Currently if I have a user or team that is assigned the Tenant Manager role that is scoped to specific tenants they are unable to view any of the tenants they create. Instead they could create the tenant but would then need someone to add the new tenant to the role scope

Both TeamCity and Jenkins have plugins that allow exporting opentelemetry data to any collector service supporting the OTLP protocol. It would be nice if Octopus Deploy also supported this as well, so we could get a full picture of the pipeline, and have metrics on time to deployment from commit to deployment.

Octopus is getting used more and more with Linux and CLI tools in the Linux ecosystem. Those tools often output ANSI codes, particularly for color.

Most of the time it's possible to turn the color output/ANSI codes off but the lack of color can make deployment logs much less readable.

Other tools in the CI/CD process do support basic ANSI codes (color), eg. Github Actions, Gitlab CI, Jenkins etc.

As an example of log output that is much more difficult to read without color: terraform plan

We currently have files inside our git repository, in order to use them in Octopus, we have to create a build in jenkins just to zip it up and upload it to Octopus built in packages

It would be nice if we could just target my bitbucket repository instead of having to create jenkins builds, but more specifically GIT as that would support more than specific version control

Generally, once a deployment is triggered I tend to change browser tab and continue with other work. Sometimes, I miss a failed deployment due to continuing with work and assuming everything has been successful. It would be great to have a sound that is triggered from the browser tab when a successful or failed deployment has happened. It would really help me cut the feedback look and notify parties of success / failure.

When a deployment has failed, it shows on a tenanted dashboard as the latest release, when I'm wanting to know which version was last deployed/currently active (our deployments rollback if unsuccessful), but right now there's no way on showing only success deployments.

It would be a great feature for this to be one of the Advanced Filters options.

Also, maybe as a side and could be a bug, that latest release number, even if failed, actually shows up as the current released version when doing a multi deployment i.e. using the Deploy To window

We've had multiple teams running into this problem in their deployments/runbooks.

When starting up a long running process (i.e. Start-Process Some.exe), Octopus deployment step never completes until the process on remote target ends.

Currently, the recommended workaround is wrapping the server process in a Windows scheduled task.

As described here:
https://help.octopus.com/t/long-running-console-applications/10408

It would be helpful if this functionality was added as out-of-box.

Thanks,

Ge