When I use the Export function in Audit, the Details column is a mix of HTML and JSON.
For example:

<span>{<br> "Id": "variableset-LibraryVariableSets-76",<br> "OwnerId": "LibraryVariableSets-76",<br> "Version": 11</span><del style="background:#ffe6e6;">5</del><ins style="background:#e6ffe6;">6</ins><span><br>}</span>

I understand that this is a way to show what the changes were, but this format is only usable for display in HTML, not for parsing the exported audit via any tools.
Would it be possible to export this as JSON and indicate the change in some other, structural way?
E.g.

{ "Id": "variableset-LibraryVariableSets-76", "OwnerId": "LibraryVariableSets-76", "Version": { "OldValue": 115, "NewValue": 116 } }

Or in any other way which would allow to access this data programatically.

(originally posted on https://help.octopus.com/t/audit-export-returns-json-mixed-with-html-tags/24312)

Right now defining the Release Versioning approach happens at the Project level. When there are multiple channels, it would be nice to instead define them at the Channel level. In the case where you may be deploying 2020.1.0 and 2020.2.0 releases to different environments, if you change channels you have to go change the Release Version at that time as well. Then if you have automatic releases setup it will increment against an incorrect version.

Example:
"Test" channel limits to 2020.2.0 packages. Create an Octo Release 2020.2.0.1 and release.

Then create a release for a "HotFix" channel which limits to 2020.1.1 packages. Create an Octo Release, it will default to 2020.2.0.2. Change to 2020.1.1.1 and create.

Auto Release for Test runs and creates a release on the "Test" channel with 2020.1.1.2 release version.

** If Release Versioning was at the channel level, it would remedy this.

Imagine you have a connection string variable and you want to update it. You would update the variable and redeploy, however if you made a mistake (edited the wrong variable or the new connection string was not live yet) then you cannot roll back. This is even more of a problem if the variable is sensitive as you can't copy it beforehand.

I would like to be able to version octopus variables, this would include:
- Who
- When
- When deployed
- The ability to roll back/forward.

At the moment we have to source control much of this type work, this obviously negates much of the valuable octopus functionality around environment handling/sensitive variables.

When deploying application containers, there can be times when you want a password that no human needs to know and survives only for the lifetime of the container.

Our primary use case is generating secure keystores for certificates, etc. At container start-up, it will generate a new local keystore and we then have the ability to dynamically sign CSRs generated within the container via an external signing service.

We do not want to leave the keystore nor the certificate objects without any password, but also do not want to store the values anywhere external to the container.

Granted, we certainly can do things like set a short certificate lifetime, adopt policies such rapid container cycling, etc. in addition as a layered approach, but I see no reason to externally persist secrets that are of no use and add operational overhead to cycle manually.

Add a PROCESS SNAPSHOT option for releases with an UPDATE PROCESSES button. This is the same thing that Octopus already has for variables. Just do it for Processes!

Nothing worse than having to make a small powershell script change then create a new release and run it back up the runway or having to temporarily manipulate the lifecycle to get it re-deployed to where you want it to go with the updated process.

I want to be able to go to the release. Hit update processes for that release to what I just changed on any process then be able to just re-deploy the same release to that environment with the steps i want to go.

Feel free to shoot it down boys. I'm all ears on why this is a bad idea.

Packer is a versatile tool, especially when working in a multi-cloud environment. It can be used for both creating both base gold images that can then be fully built on later or fully built imputable images.

I see an octopus step being able to be used to:
1) create or pull (from a repository) & update a json template with variables & transformation.
2) next packer validate
3) packer builds the image.

ideally, there would also be an "Octopus" provisioner for packer that would allow the download of repos, call templates, transforms, variables install tenticle via cli

but even it only did the first three you could still use existing PowerShell & bash scripting

The resulting image details ( from packer manifest provisioner) could then be returned to octopus as variables to be used in other process tasks such as launch an instance that octopus would then manage.