Merge pull request #2068 from OctopusDeploy/sast/VersionNumbers

Readjusting the version numbers

dictionary-octopus.txt

@@ -1,5 +1,10 @@
 apikey
 astro
+bootstrap
+bootstrapped
+bootstrapper
+cscfg
+cspkg
 cutover
 datetime
 deallocate
@@ -22,6 +27,7 @@ MTTR
 Netscaler
 nologs
 NTLM
+nupkg
 Octo
 octobak
 Octopub
@@ -35,13 +41,15 @@ OIDC
 onlylogs
 passout
 pkcs
+PROGRAMFILES
 reprioritize
 reprovisioned
 reprovisioning
 Runbook
 runbook
 runbooks
 Schannel
+SIEM
 signingkeys
 sthumb
 swaggerui
@@ -51,6 +59,7 @@ Trivy
 upgradelog
 WCAG
 webfonts
+WEBSVR
 WIXUI
 workertools
 xlarge

src/pages/docs/infrastructure/deployment-targets/machine-policies.mdx

@@ -49,19 +49,19 @@ Octopus will automatically push the latest version of Calamari with your first d
 1. From the Infrastructure tab, select deployment targets.
 2. Click the ... overflow menu and select **Upgrade Calamari on Deployment Targets**.
 
-### Health check interval \{#MachinePolicies-Healthcheckinterval}
+### Health check interval
 
 You can set the "Time between checks" to control how frequently automatic health checks run.
 
 :::figure
 ![](/docs/infrastructure/deployment-targets/images/5865585.png "width=500")
 :::
 
-### Health check type \{#MachinePolicies-Healthchecktype}
+### Health check type
 
 You can configure health checks to run scripts on deployment targets, or just check that a connection can be established with the deployment target. When the "Run health check scripts" option is selected you will also have the opportunity to customize the PowerShell and Bash scripts that will be executed during the health check. The "Only perform connection test" option is recommended if you are using the raw scripting feature.
 
-### Custom health check scripts \{#MachinePolicies-Customhealthcheckscripts}
+### Custom health check scripts \{#custom-health-check-scripts}
 
 Machine policies allow the configuration of custom health check scripts for Tentacle and SSH deployment targets. While we do not expose the full underlying script that runs during health checks, we give you an entry point to inject your own custom scripts. For example, here is the default custom health check script for PowerShell that checks disk space:
 
@@ -113,7 +113,7 @@ fail_healthcheck "This is an error"
 When using a custom health check script, the script execution through Calamari is bypassed. This results in some behavioral differences compared with the normal scripting in Octopus that you would be accustomed to. You can still use the standard `#` variable substitution syntax, however since this is replaced on the server, environment variables from your target will not be available through Octopus variables.
 :::
 
-## Ignore machines that are unavailable during health checks \{#MachinePolicies-Ignoremachinesthatareunavailableduringhealthchecks}
+## Ignore machines that are unavailable during health checks
 
 By default, health checks fail if any deployment targets are unavailable during the health check.  Machine policies offer an option to ignore machines if they are unavailable during a health check:
 
@@ -123,7 +123,7 @@ By default, health checks fail if any deployment targets are unavailable during
 
 By selecting **Unavailable machines will not cause health checks to fail,** any deployment targets that Octopus cannot contact during a health check will be skipped and the health check marked as successful. If the target is contactable but encounters an error or warning, the usual health check behavior will proceed (i.e., a warning will be reported or the health check will fail with an error).
 
-## Configure how Calamari and Tentacle are updated \{#MachinePolicies-ConfigurehowCalamariandTentacleareupdated}
+## Configure how Calamari and Tentacle are updated
 
 Brand new Tentacle and SSH endpoints require the installation of Calamari to perform a deployment.  Also, if Calamari is updated, the Octopus Server will push the update to Tentacle and SSH endpoints. When there is a Tentacle update, Octopus can automatically update Tentacle endpoints.  Machine policies allow the customization of when Calamari and Tentacle updates occur.
 
@@ -138,7 +138,7 @@ By default, Calamari will be installed or updated when a machine is involved in
 
 Tentacle can be toggled to manually or automatically update.  If **Automatically** is selected, Octopus will start a task to update Tentacles whenever Octopus detects that there is a pending Tentacle upgrade (after health checks for example). Conversely, Octopus will not automatically update Tentacle but instead will display a prompt to begin a Tentacle update on the Deployment Targets and Environments screens.
 
-### Maximum number of concurrent upgrades \{#MachinePolicies-MaxCalamariUpgrades}
+### Maximum number of concurrent upgrades
 
 There is a limit to the number of concurrent upgrades possible when choosing `Always keep Calamari up to date`. This ensures that upgrades do not adversely effect the performance of your Octopus Server.
 
@@ -150,10 +150,10 @@ You can select a username/password account to perform automatic Tentacle updates
 
 **Note:** This option can not be used when Tentacle is running as Local System.
 
-## Recover from communication errors with Tentacle \{#MachinePolicies-Recoverfromcommunicationerrorswithtentacle}
+## Recover from communication errors with Tentacle \{#recover-from-communication-errors}
 
 :::div{.hint}
-Recovering from communication errors with Tentacle is available to **Cloud** customers from **Octopus 2023.3** onwards and will be made available to self-hosted customers in a future release.
+Recovering from communication errors with Tentacle is available from **Octopus 2023.4** onwards.
 :::
 
 You can configure whether Octopus Deploy should re-attempt failed communications with a Tentacle for a set duration when a network error occurs. This is particularly useful to reduce deployment failures that occur when Tentacle is on an unstable network connection.
@@ -180,15 +180,15 @@ You can configure the amount of time allowed for Octopus to re-attempt failed co
 ### Step Retries and execution timeouts
 If you would like to retry a particular step within the deployment process for other types of temporary or transient errors, that can be [configured separately](/docs/projects/steps/conditions/#retries-and-execution-timeouts).
 
-## Automatically delete machines \{#MachinePolicies-Automaticallydeletemachines}
+## Automatically delete machines
 
 Machine policies can be configured to automatically remove unavailable machines after a time period.  When a health check runs, Octopus detects if machines are unavailable (cannot be contacted). When the **Automatically delete unavailable machines** option is set, Octopus checks how long a machine has been unavailable.  If the specified time period has elapsed, the machine is permanently deleted from Octopus.
 
 :::figure
 ![](/docs/infrastructure/deployment-targets/images/5865595.png "width=500")
 :::
 
-## Assign machine policies to machines \{#MachinePolicies-Assignmachinepoliciestomachines}
+## Assign machine policies to machines
 
 Assign a machine policy to a machine by selecting a machine from the *Environments* screen and using the *Policy* drop down to select the machine policy:
 

src/pages/docs/packaging-applications/package-repositories/index.md

@@ -32,16 +32,16 @@ Your package repository will typically be:
 - A [MyGet](http://www.myget.org/) server.
 - An [Azure DevOps or TFS Package Management](/docs/packaging-applications/package-repositories/guides/nuget-repositories/tfs-azure-devops).
 
-## Choosing the right repository {#Packagerepositories-Choosingtherightrepository}
+## Choosing the right repository {#choose-right-repository}
 
 Because Octopus can consume packages from multiple feeds, we recommend using different repositories for different  purposes as each repository provides different benefits. For instance, if you produce your own application library packages in addition to your deployment packages you might consider something like the following:
 
 - Use the [built-in repository](/docs/packaging-applications/package-repositories/built-in-repository/) for your deployment packages. This is generally the best choice as it offers better performance and through the [retention policies](/docs/administration/retention-policies) you've configured, Octopus knows which packages are no longer required and can be cleaned up.
 - For application library packages consider using the repository provided by your [build server](/docs/packaging-applications/build-servers), a [file-share](http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds#Creating_Local_Feeds), [MyGet](http://www.myget.org/ "MyGet"), or [Azure DevOps Package Management](https://www.visualstudio.com/en-us/docs/package/overview).
 - For deployment scripts that you want to store in your source control and where a build process is unnecessary, [GitHub feeds](/docs/packaging-applications/package-repositories/github-feeds) might be suitable.
 
-## Planning package repository placement {#Packagerepositories-Placement}
+## Planning package repository placement
 
-By default, when you [deploy a package](/docs/deployments/packages) to a Tentacle, the package will be pushed from the Octopus Server to the Tentacle. You can override this by changing the setting of the [Action System Variable](/docs/projects/variables/system-variables/#Systemvariables-Action) `Octopus.Action.Package.DownloadOnTentacle` from `False` to `True`. When set to `True` the package will be downloaded by the Tentacle, rather than pushed by the Octopus Server.
+By default, when you [deploy a package](/docs/deployments/packages) to a Tentacle, the package will be pushed from the Octopus Server to the Tentacle. You can override this by changing the setting of the [Action System Variable](/docs/projects/variables/system-variables/#action) `Octopus.Action.Package.DownloadOnTentacle` from `False` to `True`. When set to `True` the package will be downloaded by the Tentacle, rather than pushed by the Octopus Server.
 
 To reduce network latency, when your package repository is in close proximity to the Octopus Server leave `Octopus.Action.Package.DownloadOnTentacle` set to the default value of `False`. Alternatively, if you have explicitly set the Tentacles to download packages by the Tentacle to `True`, you should consider placing your package repository in close proximity to your Tentacles.

src/pages/docs/projects/built-in-step-templates/health-check.md

@@ -31,7 +31,7 @@ Health check steps are added to deployment and runbook processes in the same way
 2. In the **On Behalf Of** section, select the [target roles](/docs/infrastructure/deployment-targets/#target-roles) that match the deployment targets you want to run a health check against. 
 
 3. In the **Health check** section select an option for **Health check type**:
-    - Perform a full health check - this will run the [health check script](/docs/infrastructure/deployment-targets/machine-policies/#MachinePolicies-Customhealthcheckscripts) defined by the machine policy.
+    - Perform a full health check - this will run the [health check script](/docs/infrastructure/deployment-targets/machine-policies/#custom-health-check-scripts) defined by the machine policy.
     - Perform a connection-only test - this only checks the machine is available (connected).
 
    For **Health check errors**, select which action to take on a health check error:

src/pages/docs/projects/deployment-process/performance.md

@@ -109,7 +109,7 @@ Each option provides different performance benefits, depending on your specific
 
 Imagine if you keep every package you've ever built or deployed. Over time your package feed will get slower and slower to index, query, and stream packages for your deployments.
 
-If you are using the [built-in feed](/docs/packaging-applications/package-repositories/#Packagerepositories-Choosingtherightrepository), you can configure [retention policies](/docs/administration/retention-policies) to keep it running fast.
+If you are using the [built-in feed](/docs/packaging-applications/package-repositories/#choose-right-repository), you can configure [retention policies](/docs/administration/retention-policies) to keep it running fast.
 
 If you are using another feed, you should configure its retention policies yourself, making sure to cater for packages you may want to deploy.
 

src/pages/docs/projects/steps/conditions/index.mdx

@@ -62,7 +62,7 @@ You can achieve the opposite effect by swapping `unless` with `if`:
 #{if Octopus.Deployment.Error}#{Variable}#{/if}
 ```
 
-It's also possible to check the status of specific [steps and actions](/docs/projects/variables/system-variables/#Systemvariables-DeploymentStatusTrackingdeploymentstatus).
+It's also possible to check the status of specific [steps and actions](/docs/projects/variables/system-variables/#tracking-deployment-status).
 
 ### Machine-level variable expressions
 
@@ -167,7 +167,7 @@ This functionality is available on all other steps.
 ### Retries
 Enabling Retries gives you the ability to automatically retry a step if it fails, with up to three attempts. This feature is particularly useful when dealing with steps that commonly fail due to temporary or transient errors during deployment.
 
- You can also [recover from communication errors with a tentacle](/docs/infrastructure/deployment-targets/machine-policies/#MachinePolicies-Recoverfromcommunicationerrorswithtentacle) to reduce deployment failures that occur when Tentacle is on an unstable network connection.
+ You can also [recover from communication errors with a tentacle](/docs/infrastructure/deployment-targets/machine-policies/#recover-from-communication-errors) to reduce deployment failures that occur when Tentacle is on an unstable network connection.
 
 ### Timeouts
 When the configured Execution Timeout period has lapsed, the action will be cancelled.    

src/pages/docs/projects/variables/system-variables.md

@@ -16,7 +16,7 @@ Most of the variables listed here are available in modern versions of Octopus an
 Note that when evaluating values, **all Octopus variables are strings** even if they look like numbers or other data types.
 :::
 
-## Release {#Systemvariables-Release}
+## Release {#release}
 
 Release-level variables are drawn from the project and release being created.
 
@@ -298,7 +298,7 @@ For projects that have [version control](/docs/projects/version-control) enabled
 
  Example: *Version 1*
 
-## Deployment {#Systemvariables-Deployment}
+## Deployment
 
 Deployment-level variables are drawn from the project and release being deployed.
 
@@ -511,13 +511,13 @@ Example: *OctoFx*
 
 `Octopus.ProjectGroup.Id`
 
-The ID of the projectgroup.
+The ID of the project group.
 
-Example: *projectgroups-123*
+Example: *project-groups-123*
 
 `Octopus.ProjectGroup.Name`
 
-The name of the projectgroup.
+The name of the project group.
 
 Example: *Public Web Properties*
 
@@ -609,7 +609,7 @@ Example: *deployments-123*
 
 The ID of the task.
 
-Example: *servertasks-123*
+Example: *server-tasks-123*
 
 `Octopus.Task.Name`
 
@@ -765,7 +765,7 @@ The distinct targets being deployed to.
 
 This provides a dictionary of objects with ID and Name properties, keyed on ID. This is a distinct list across all steps in the deployment process.
 
-## Action {#Systemvariables-Action}
+## Action {#action}
 
 Action-level variables are available during execution of an action. Indexer notion such as `Octopus.Action[Website].TargetRoles` can be used to refer to values for different actions.
 
@@ -915,7 +915,7 @@ Example: *web-server,frontend*
 
 If the action is based on a step template, the ID of the template.
 
-Example: *actiontemplates-123*
+Example: *action-templates-123*
 
 `Octopus.Action.Template.Version`
 
@@ -987,7 +987,7 @@ The name of the package file (if the package has been configured to not be extra
 
 Example: *Acme.zip*
 
-## Azure {#Systemvariables-Azure}
+## Azure
 
 `Octopus.Action.Azure.CertificateThumbprint`
 
@@ -1011,9 +1011,9 @@ Example: *8affaa7d-3d74-427c-93c5-2d7f6a16e754*
 
 Override the auto-generated resource group deployment name when deploying a resource group.
 
-Example: my-resourcegroupdeployment-name
+Example: my-resource-group-deployment-name
 
-## Azure Cloud Service {#Systemvariables-AzureCloudService}
+## Azure Cloud Service
 
 `Octopus.Action.Azure.CloudServiceConfigurationFileRelativePath`
 
@@ -1025,7 +1025,7 @@ Example: *ServiceConfiguration.Custom.cscfg*
 
 The name of the Cloud Service being targeted by this action.
 
-Example: *my-cloudservice-web*
+Example: *my-cloud-service-web*
 
 `Octopus.Action.Azure.CloudServicePackageExtractionDisabled`
 
@@ -1037,7 +1037,7 @@ Example: True
 
 The path of the \*.cspkg file used by this action.
 
-Example: *Z:\Temp\packages\my-cloudservice-web.cspkg*
+Example: *Z:\Temp\packages\my-cloud-service-web.cspkg*
 
 `Octopus.Action.Azure.LogExtractedCspkg`
 
@@ -1081,7 +1081,7 @@ If set, the custom deployment label will be used for the Azure cloud service dep
 
 Example: my custom label for build 3.x.x
 
-## Azure Web Apps {#Systemvariables-AzureWebApps}
+## Azure Web Apps
 
 `Octopus.Action.Azure.WebAppName`
 
@@ -1099,7 +1099,7 @@ Example: *staging*
 
 The name of the resource group being targeted by this deployment.
 
-Example: myresourcegroup
+Example: MyResourceGroup
 
 `Octopus.Action.Azure.RemoveAdditionalFiles`
 
@@ -1119,7 +1119,7 @@ When *True* instructs Web Deploy to safely bring down the app domain by adding a
 
 Example: *True*
 
-## Output {#Systemvariables-Output}
+## Output
 
 Output variables are collected during execution of a step and made available to subsequent steps using notation such as `Octopus.Action[Website].Output[WEBSVR01].Package.InstallationDirectoryPath`to refer to values base on the action and machine that produced them. See also [Output variables](/docs/projects/variables/output-variables).
 
@@ -1177,7 +1177,7 @@ The Url of the completed Azure Cloud Service deployment. **Introduced in Calamar
 
 Example: *http://c9f52da2b00a4313b3b64bb2ad0f409f.cloudapp.net/*
 
-## Step {#Systemvariables-Step}
+## Step
 
 Step-level variables are available during execution of a step. Indexer notion such as `Octopus.Step[Website].Number` can be used to refer to values for different steps.
 
@@ -1218,7 +1218,7 @@ If the step failed because of an error, a full description of the error.
 Example: *System.Net.SocketException: The server could not be contacted (at ...)*
 
 
-## Agent {#Systemvariables-Agent}
+## Agent
 
 Agent-level variables describe the deployment agent or Tentacle on which the deployment is executing.
 
@@ -1246,7 +1246,7 @@ The directory containing either the server or Tentacle's executables depending o
 
 Example: *C:\Program Files\Octopus Deploy\Octopus*
 
-## Worker Pool {#Systemvariables-WorkerPool}
+## Worker Pool
 
 When a step is run on a worker, the following variables are available:
 
@@ -1262,7 +1262,7 @@ The name of the pool.
 
 Example: Default Worker Pool
 
-## Server {#Systemvariables-Server}
+## Server
 
 Server-level variables describe the Octopus Server on which the deployment is running.
 
@@ -1278,7 +1278,7 @@ The default URL at which the server portal can be accessed, as configured in the
 
 *[https://my-octopus](https://my-octopus)*
 
-## Tracking deployment status {#Systemvariables-DeploymentStatusTrackingdeploymentstatus}
+## Tracking deployment status {#tracking-deployment-status}
 
 During deployment, Octopus provides variables describing the status of each step.
 
@@ -1310,7 +1310,7 @@ Octopus.Deployment.ErrorDetail
 Octopus.Deployment.Error and Octopus.Deployment.ErrorDetail will only display the exit code and Octopus stack trace for the error. As we cannot parse the deployment log, we can only extract the exit/error codes. It cannot show detailed information on what caused the error. For full information on what happened when the deployment fails, you will need to reference the logs.
 :::
 
-## Runbook {#Systemvariables-Runbook}
+## Runbook
 
 `Octopus.Runbook.Id`
 
@@ -1358,7 +1358,7 @@ Example: *RunbookSnapshots-123*
 
 The name of the snapshot.
 
-*Snapshot SGKSPY3*
+*Snapshot EXAMPLE3*
 
 `Octopus.RunbookSnapshot.Notes`
 
@@ -1378,7 +1378,7 @@ A path relative to the Octopus Server URL at which the runbook run can be viewed
 
 Example: */app/runs/runbookRuns-123*
 
-## User-modifiable settings {#Systemvariables-User-modifiablesettings}
+## User-modifiable settings {#user-modifiable-settings}
 
 The following variables can be defined as variables in your project to modify the way Octopus behaves.