diff --git a/src/pages/docs/kubernetes/targets/kubernetes-agent/index.md b/src/pages/docs/kubernetes/targets/kubernetes-agent/index.md index 97ec4ef0bc..4a4f970057 100644 --- a/src/pages/docs/kubernetes/targets/kubernetes-agent/index.md +++ b/src/pages/docs/kubernetes/targets/kubernetes-agent/index.md @@ -98,17 +98,20 @@ The Kubernetes agent is installed using [Helm](https://helm.sh) via the [octopus To simplify this, there is an installation wizard in Octopus to generate the required values. :::div{.warning} + Helm will use your current kubectl config, so make sure your kubectl config is pointing to the correct cluster before executing the following helm commands. You can see the current kubectl config by executing: + ```bash kubectl config view ``` + ::: ### Configuration 1. Navigate to **Infrastructure ➜ Deployment Targets**, and click **Add Deployment Target**. -2. Select **KUBERNETES** and click **ADD** on the Kubernetes Agent card. +2. Select **KUBERNETES** and click **ADD** on the Kubernetes Agent card. 3. This launches the Add New Kubernetes Agent dialog :::figure @@ -133,7 +136,7 @@ If you do want a Kubernetes agent and Kubernetes worker to have the same name, T ![Kubernetes Agent default namespace](/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-default-namespace.png) ::: -You can choose a default Kubernetes namespace that resources are deployed to. This is only used if the step configuration or Kubernetes manifests don’t specify a namespace. +You can choose a default Kubernetes namespace that resources are deployed to. This is only used if the step configuration or Kubernetes manifests don't specify a namespace. ### NFS CSI driver @@ -146,10 +149,13 @@ A requirement of using the NFS pod is the installation of the [NFS CSI Driver](h ::: :::div{.warning} + If you receive an error with the text `failed to download` or `no cached repo found` when attempting to install the NFS CSI driver via helm, try executing the following command and then retrying the install command: + ```bash helm repo update ``` + ::: ### Installation helm command @@ -184,13 +190,14 @@ While the wizard doesn't support selecting Tenants or Tenant tags, the agent can 1. Use the Deployment Target settings UI at **Infrastructure ➜ Deployment Targets ➜ [DEPLOYMENT TARGET] ➜ Settings** to add a Tenant and set the Tenanted Deployment Participation as required. This is done after the agent has successfully installed and registered. -:::figure -![Kubernetes Agent ](/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-settings-page-tenants.png) -::: + :::figure + ![Kubernetes Agent ](/docs/img/infrastructure/deployment-targets/kubernetes/kubernetes-agent/kubernetes-agent-settings-page-tenants.png) + ::: 2. Set additional variables in the helm command to allow the agent to register itself with associated Tenants or Tenant tags. You also need to provider a value for the `TenantedDeploymentParticipation` value. Possible values are `Untenanted` (default), `Tenanted`, and `TenantedOrUntenanted`. example to add these values: + ```bash --set agent.tenants="{,}" \ --set agent.tenantTags="{,}" \ @@ -202,6 +209,7 @@ You don't need to provide both Tenants and Tenant Tags, but you do need to provi ::: In a full command: + ```bash helm upgrade --install --atomic \ --set agent.acceptEula="Y" \ @@ -229,7 +237,7 @@ Server certificate support was added in Kubernetes agent 1.7.0 It is common for organizations to have their Octopus Deploy server hosted in an environment where it has an SSL/TLS certificate that is not part of the global certificate trust chain. As a result, the Kubernetes agent will fail to register with the target server due to certificate errors. A typical error looks like this: -``` +```text 2024-06-21 04:12:01.4189 | ERROR | The following certificate errors were encountered when establishing the HTTPS connection to the server: RemoteCertificateNameMismatch, RemoteCertificateChainErrors Certificate subject name: CN=octopus.corp.domain Certificate thumbprint: 42983C1D517D597B74CDF23F054BBC106F4BB32F @@ -237,7 +245,7 @@ Certificate thumbprint: 42983C1D517D597B74CDF23F054BBC106F4BB32F To resolve this, you need to provide the Kubernetes agent with a base64-encoded string of the public key of either the self-signed certificate or root organization CA certificate in either `.pem` or `.crt` format. When viewed as text, this will look similar to this: -``` +```text -----BEGIN CERTIFICATE----- MII... -----END CERTIFICATE----- @@ -277,7 +285,7 @@ For the `Run a kubectl script` step, if there is a [container image](/docs/proje To override these automatically resolved tooling images, you can set the helm chart values of `scriptPods.worker.image.repository` and `scriptPods.worker.image.tag` for the agent running as a worker, or `scriptPods.deploymentTarget.image` and `scriptPods.deploymentTarget.tag` when running the agent as a deployment target. :::div{.warning} -In Octopus Server versions prior to `2024.3.7669`, the Kubernetes agent erroneously used container images defined in _all_ Kubernetes steps, not just the `Run a kubectl script` step. +In Octopus Server versions prior to `2024.3.7669`, the Kubernetes agent erroneously used container images defined in *all* Kubernetes steps, not just the `Run a kubectl script` step. ::: This image contains the minimum required tooling to run Kubernetes workloads for Octopus Deploy, namely: @@ -311,15 +319,17 @@ To check if a Kubernetes agent can be manually upgraded, navigate to the **Infra ### Helm upgrade command To upgrade a Kubernetes agent via `helm`, note the following fields from the **Infrastructure ➜ Deployment Targets ➜ [DEPLOYMENT TARGET] ➜ Connectivity** page: -* Helm Release Name -* Namespace + +- Helm Release Name +- Namespace Then, from a terminal connected to the cluster containing the instance, execute the following command: ```bash helm upgrade --atomic --namespace NAMESPACE HELM_RELEASE_NAME oci://registry-1.docker.io/octopusdeploy/kubernetes-agent ``` -__Replace NAMESPACE and HELM_RELEASE_NAME with the values noted__ + +Note: Replace `NAMESPACE` and `HELM_RELEASE_NAME` with your own values. If after the upgrade command has executed, you find that there is issues with the agent, you can rollback to the previous helm release by executing: @@ -327,7 +337,6 @@ If after the upgrade command has executed, you find that there is issues with th helm rollback --namespace NAMESPACE HELM_RELEASE_NAME ``` - ## Uninstalling the Kubernetes agent To fully remove the Kubernetes agent, you need to delete the agent from the Kubernetes cluster as well as delete the deployment target from Octopus Deploy diff --git a/src/pages/docs/kubernetes/targets/kubernetes-api/index.md b/src/pages/docs/kubernetes/targets/kubernetes-api/index.md index ae5804088a..42118cd424 100644 --- a/src/pages/docs/kubernetes/targets/kubernetes-api/index.md +++ b/src/pages/docs/kubernetes/targets/kubernetes-api/index.md @@ -13,15 +13,14 @@ Kubernetes API targets are used by the [Kubernetes steps](/docs/deployments/kube Conceptually, a Kubernetes API target represent a permission boundary and an endpoint. Kubernetes [permissions](https://oc.to/KubernetesRBAC) and [quotas](https://oc.to/KubernetesQuotas) are defined against a namespace, and both the account and namespace are captured as a Kubernetes API target, along with the cluster endpoint URL. A namespace is required when registering the Kubernetes API target with Octopus Deploy. By default, the namespace used in the registration is used in health checks and deployments. The namespace can be overwritten in the deployment process. :::div{.hint} -From **Octopus 2022.2**, AKS target discovery has been added to the -Kubernetes Target Discovery Early Access Preview and is enabled via **Configuration ➜ Features**. +From **Octopus 2022.2**, AKS target discovery has been added to the Kubernetes Target Discovery Early Access Preview and is enabled via **Configuration ➜ Features**. From **Octopus 2022.3** will include EKS cluster support. ::: ## Discovering Kubernetes targets -Octopus can discover Kubernetes API targets in _Azure Kubernetes Service_ (AKS) or _Amazon Elastic Container Service for Kubernetes_ (EKS) as part of your deployment using tags on your AKS or EKS resource. +Octopus can discover Kubernetes API targets in *Azure Kubernetes Service* (AKS) or *Amazon Elastic Container Service for Kubernetes* (EKS) as part of your deployment using tags on your AKS or EKS resource. :::div{.hint} From **Octopus 2022.3**, you can configure the well-known variables used to discover Kubernetes targets when editing your deployment process in the Web Portal. See [cloud target discovery](/docs/infrastructure/deployment-targets/cloud-target-discovery) for more information. @@ -87,7 +86,7 @@ users: The Azure Service Principal is only used with AKS clusters. To log into ACS or ACS-Engine clusters, standard Kubernetes credentials like certificates or service account tokens must be used. - :::div{.hint} + :::div{.hint} From Kubernetes 1.26, [the default azure auth plugin has been removed from kubectl](https://github.com/kubernetes/kubernetes/blob/ad18954259eae3db51bac2274ed4ca7304b923c4/CHANGELOG/CHANGELOG-1.26.md#deprecation) so clusters targeting Kubernetes 1.26+ that have [Local Account Access disabled](https://oc.to/AKSDisableLocalAccount) in Azure, will require the worker or execution container to have access to the [kubelogin](https://oc.to/Kubelogin) CLI tool, as well as the Octopus Deployment Target setting **Login with administrator credentials** disabled. This requires **Octopus 2023.3*. If Local Account access is enabled on the AKS cluster, the Octopus Deployment Target setting Login with administrator credentials will also need to be enabled so that the Local Accounts are used instead of the default auth plugin. @@ -95,7 +94,7 @@ users: - **AWS Account**: When using an EKS cluster, [AWS accounts](/docs/infrastructure/accounts/aws) allow IAM accounts and roles to be used. - The interaction between AWS IAM and Kubernetes Role Based Access Control (RBAC) can be tricky. We highly recommend reading the [AWS documentation](https://docs.aws.amazon.com/eks/latest/userguide/managing-auth.html). + The interaction between AWS IAM and Kubernetes Role Based Access Control (RBAC) can be tricky. We highly recommend reading the [AWS documentation](https://docs.aws.amazon.com/eks/latest/userguide/managing-auth.html). :::div{.hint} **Common issues:** @@ -135,6 +134,7 @@ users: -in certificate.crt ` -inkey private.key ``` + ```bash #!/bin/bash echo $1 | base64 --decode > certificate.crt @@ -154,29 +154,31 @@ users: 7. Enter the Kubernetes cluster URL. Each Kubernetes target requires the cluster URL, which is defined in the `Kubernetes cluster URL` field. In the example YAML about, this is defined in the `server` field. 8. Optionally, select the certificate authority if you've added one. Kubernetes clusters are often protected with self-signed certificates. In the YAML example above the certificate is saved as a base 64 encoded string in the `certificate-authority-data` field. -To communicate with a Kubernetes cluster with a self-signed certificate over HTTPS, you can either select the **Skip TLS verification** option, or supply the certificate in `The optional cluster certificate authority` field. + To communicate with a Kubernetes cluster with a self-signed certificate over HTTPS, you can either select the **Skip TLS verification** option, or supply the certificate in `The optional cluster certificate authority` field. -Decoding the `certificate-authority-data` field results in a string that looks something like this (the example has been truncated for readability): + Decoding the `certificate-authority-data` field results in a string that looks something like this (the example has been truncated for readability): -``` ------BEGIN CERTIFICATE----- -XXXXXXXXXXXXXXXX... ------END CERTIFICATE----- -``` + ```text + -----BEGIN CERTIFICATE----- + XXXXXXXXXXXXXXXX... + -----END CERTIFICATE----- + ``` -Save this text to a file called `ca.pem`, and upload it to the [Octopus certificate management area](https://oc.to/CertificatesDocumentation). The certificate can then be selected in the `cluster certificate authority` field. + Save this text to a file called `ca.pem`, and upload it to the [Octopus certificate management area](https://oc.to/CertificatesDocumentation). The certificate can then be selected in the `cluster certificate authority` field. 9. Enter the Kubernetes Namespace. -When a single Kubernetes cluster is shared across environments, resources deployed to the cluster will often be separated by environment and by application, team, or service. In this situation, the recommended approach is to create a namespace for each application and environment (e.g., `my-application-development` and `my-application-production`), and create a Kubernetes service account that has permissions to just that namespace. + When a single Kubernetes cluster is shared across environments, resources deployed to the cluster will often be separated by environment and by application, team, or service. In this situation, the recommended approach is to create a namespace for each application and environment (e.g., `my-application-development` and `my-application-production`), and create a Kubernetes service account that has permissions to just that namespace. -Where each environment has its own Kubernetes cluster, namespaces can be assigned to each application, team or service (e.g. `my-application`). + Where each environment has its own Kubernetes cluster, namespaces can be assigned to each application, team or service (e.g. `my-application`). -In both scenarios, a target is then created for each Kubernetes cluster and namespace. The `Target Role` tag is set to the application name (e.g. `my-application`), and the `Environments` are set to the matching environment. + In both scenarios, a target is then created for each Kubernetes cluster and namespace. The `Target Role` tag is set to the application name (e.g. `my-application`), and the `Environments` are set to the matching environment. -When a Kubernetes target is used, the namespace it references is created automatically if it does not already exist. + When a Kubernetes target is used, the namespace it references is created automatically if it does not already exist. 10. Select a worker pool for the target. -To make use of the Kubernetes steps, the Octopus Server or workers that will run the steps need to have the `kubectl` executable installed. Linux workers also need to have the `jq`, `xargs` and `base64` applications installed. + + To make use of the Kubernetes steps, the Octopus Server or workers that will run the steps need to have the `kubectl` executable installed. Linux workers also need to have the `jq`, `xargs` and `base64` applications installed. + 11. Click **SAVE**. :::div{.warning} @@ -273,12 +275,15 @@ kubectl get secret $(kubectl get serviceaccount jenkins-deployer -o jsonpath="{. The token can then be saved as a Token Octopus account, and assigned to the Kubernetes target. :::div{.warning} + Kubernetes versions 1.24+ no longer automatically create tokens for service accounts and they need to be manually created using the **create token** command: + ```bash kubectl create token jenkins-deployer ``` -From Kubernetes version 1.29, a warning will be displayed when using automatically created Tokens. Make sure to rotate any Octopus Token Accounts to use manually created tokens via **create token** instead. +From Kubernetes version 1.29, a warning will be displayed when using automatically created Tokens. Make sure to rotate any Octopus Token Accounts to use manually created tokens via **create token** instead. + ::: ## Kubectl @@ -286,14 +291,15 @@ From Kubernetes version 1.29, a warning will be displayed when using automatical Kubernetes targets use the `kubectl` executable to communicate with the Kubernetes cluster. This executable must be available on the path on the target where the step is run. When using workers, this means the `kubectl` executable must be in the path on the worker that is executing the step. Otherwise, the `kubectl` executable must be in the path on the Octopus Server itself. ## Vendor Authentication Plugins {#vendor-authentication-plugins} + Prior to `kubectl` version 1.26, the logic for authenticating against various cloud providers (eg Azure Kubernetes Services, Google Kubernetes Engine) was included "in-tree" in `kubectl`. From version 1.26 onward, the cloud-vendor specific authentication code has been removed from `kubectl`, in favor of a plugin approach. What this means for your deployments: -* Amazon Elastic Container Services (ECS): No change required. Octopus already supports using either the AWS CLI or the `aws-iam-authenticator` plugin. -* Azure Kubernetes Services (AKS): No change required. The way Octopus authenticates against AKS clusters never used the in-tree Azure authentication code, and will continue to function as normal. - - From **Octopus 2023.3**, you will need to ensure that the [kubelogin](https://oc.to/Kubelogin) CLI tool is also available if you have disabled local Kubernetes accounts. -* Google Kubernetes Engine (GKE): If you upgrade to `kubectl` 1.26 or higher, you will need to ensure that the `gke-gcloud-auth-plugin` tool is also available. More information can be found on [Google's announcement about this change](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke). +- Amazon Elastic Container Services (ECS): No change required. Octopus already supports using either the AWS CLI or the `aws-iam-authenticator` plugin. +- Azure Kubernetes Services (AKS): No change required. The way Octopus authenticates against AKS clusters never used the in-tree Azure authentication code, and will continue to function as normal. + - From **Octopus 2023.3**, you will need to ensure that the [kubelogin](https://oc.to/Kubelogin) CLI tool is also available if you have disabled local Kubernetes accounts. +- Google Kubernetes Engine (GKE): If you upgrade to `kubectl` 1.26 or higher, you will need to ensure that the `gke-gcloud-auth-plugin` tool is also available. More information can be found on [Google's announcement about this change](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke). ## Helm @@ -313,6 +319,8 @@ If you're running into issues with your Kubernetes targets, it's possible you'll Setting the Octopus variable `Octopus.Action.Kubernetes.OutputKubeConfig` to `True` for any deployment or runbook using a Kubernetes target will cause the generated kube config file to be printed into the logs (with passwords masked). This can be used to verify the configuration file used to connect to the Kubernetes cluster. +Setting the Octopus variable `Octopus.Action.Kubernetes.VerboseOutput` to `True` will cause successful output from Kubernetes CLI tools (`kubectl`, `helm`, `aws`, `az`, `gcloud`, etc.) to be logged at the Info level instead of Verbose. This is useful when debugging deployments to see the full output of these tools without needing to enable verbose logging for the entire deployment. + If Kubernetes targets fail their health checks, the best way to diagnose the issue to to run a `Run a kubectl CLI Script` step with a script that can inspect the various settings that must be in place for a Kubernetes target to function correctly. Octopus deployments will run against unhealthy targets by default, so the fact that the target failed its health check does not prevent these kinds of debugging steps from running. An example script for debugging a Kubernetes target is shown below: diff --git a/src/pages/docs/projects/variables/system-variables.md b/src/pages/docs/projects/variables/system-variables.md index 9bb6f1425d..74400a63d6 100644 --- a/src/pages/docs/projects/variables/system-variables.md +++ b/src/pages/docs/projects/variables/system-variables.md @@ -10,7 +10,7 @@ navOrder: 20 This page lists built-in [variables](/docs/projects/variables/) provided by Octopus that can be used in your deployment [custom scripts](/docs/deployments/custom-scripts). -Most of the variables listed here are available in modern versions of Octopus and Calamari. However, some are only available from a specific version. See [Older versions](#older-versions) for more detail on when variables became available. +Most of the variables listed here are available in modern versions of Octopus and Calamari. However, some are only available from a specific version. See [Older versions](#older-versions) for more detail on when variables became available. :::div{.warning} **All variables are strings** @@ -62,12 +62,12 @@ Packages, including changes, associated with the release. See below. This is a c Build and version control details associated with the release. This is a collection. -:::div{.hint} +:::div{.hint} The `Octopus.Release.Package` and `Octopus.Release.Builds` variables: -* will only be populated if [build information](/docs/packaging-applications/build-servers/build-information) has been pushed from the build server. -* is only available to be used by the project [release notes](/docs/releases/release-notes), it is not accessible from the project deployment steps. +- will only be populated if [build information](/docs/packaging-applications/build-servers/build-information) has been pushed from the build server. +- is only available to be used by the project [release notes](/docs/releases/release-notes), it is not accessible from the project deployment steps. ::: @@ -101,7 +101,7 @@ public class Commit The packages in a release are available as a collection which can be [iterated over](/docs/projects/variables/variable-substitutions/#repetition). e.g. -``` +```text #{each package in Octopus.Release.Package} This release contains #{package.PackageId} #{package.Version} #{/each} @@ -109,22 +109,22 @@ The packages in a release are available as a collection which can be [iterated o A particular package can be selected by indexing on the package ID: -``` +```text #{Octopus.Release.Package[Acme.Web].Version} ``` The variables available for packages are: -| Name | Example| -| -------------------- | -------| -|`PackageId`| `#{package.PackageId}` | -|`Version`| `#{package.Version}` | -|`Commits`| This is a collection. See below. | -|`WorkItems`| This is a collection. See below. | +| Name | Example | +| ----------- | --------------------------------- | +| `PackageId` | `#{package.PackageId}` | +| `Version` | `#{package.Version}` | +| `Commits` | This is a collection. See below. | +| `WorkItems` | This is a collection. See below. | On each package, the commits associated with that package are available as a collection which can be iterated over. e.g.: -``` +```text #{each package in Octopus.Release.Package} #{each commit in package.Commits} - [#{commit.CommitId}](#{commit.LinkUrl}) - #{commit.Comment} @@ -134,21 +134,21 @@ On each package, the commits associated with that package are available as a col A particular commit can be selected by indexing on the commit ID (when using git the commit ID is the commit hash): -``` +```text package.Commits[685afd4161d085e6e5f56a66e72e2298e402b114].Comment ``` The variables available for commits are: -| Name | Example| -| -------------------- | -------| -|`CommitId`| `#{commit.CommitId}` | -|`LinkUrl`| `#{commit.LinkUrl}` | -|`Comment`| `#{commit.Comment}` | +| Name | Example | +| ---------- | -------------------- | +| `CommitId` | `#{commit.CommitId}` | +| `LinkUrl` | `#{commit.LinkUrl}` | +| `Comment` | `#{commit.Comment}` | If the Octopus instance has one or more of the [Issue Tracker integrations](/docs/releases/issue-tracking) enabled, the commit messages will be parsed for issues. Any issues found will be displayed with the build information, and also available as variables: -``` +```text #{each issue in package.WorkItems} - [#{issue.Id}](#{issue.LinkUrl}) #{/each} @@ -156,20 +156,20 @@ If the Octopus instance has one or more of the [Issue Tracker integrations](/doc A particular issue can be selected by indexing on the ID: -``` +```text package.WorkItems[4465].LinkUrl ``` The variables available for issues are: -| Name | Example| -| -------------------- | -------| -|`Id`| `#{issue.Id}` | -|`LinkUrl`| `#{issue.LinkUrl}` | +| Name | Example | +| --------- | ------------------ | +| `Id` | `#{issue.Id}` | +| `LinkUrl` | `#{issue.LinkUrl}` | There is also a distinct list of issues across all packages available in: -``` +```text #{each workItem in Octopus.Release.WorkItems} - [#{workItem.Id}](#{workItem.LinkUrl}) - #{workItem.Description} #{/each} @@ -202,7 +202,7 @@ public class BuildPackage The builds in a release are available as a collection which can be [iterated over](/docs/projects/variables/variable-substitutions/#repetition). e.g. -``` +```text #{each build in Octopus.Release.Builds} This release contains resources contributed by the build #{build.BuildUrl} #{/each} @@ -210,7 +210,7 @@ The builds in a release are available as a collection which can be [iterated ove Builds have a zero-based integer index, meaning the first build can be selected at index 0: -``` +```text Octopus.Release.Builds[0].BuildUrl ``` @@ -289,21 +289,21 @@ Example: `#{build.Packages[0].Version}` For projects that have [version control](/docs/projects/version-control) enabled, information about the branch and commit from which the release was created is also available. `Octopus.Release.Git.BranchName` - + The branch name. - + Example: *features/some-new-feature* `Octopus.Release.Git.CommitHash` - - The commit hash. - + + The commit hash. + Example: *0c708fdec272bc4446c6cabea4f0022c2b616eba* `Octopus.Release.Git.Ref` - + The git reference. - + Example: *Version 1* ## Deployment @@ -432,15 +432,15 @@ Example: *Tenant type/External, Upgrade ring/Early adopter* `Octopus.Deployment.Trigger.Id` -The ID of the Trigger that created the deployment. It is possible for a deployment to be triggered due to multiple triggers. In this case, the variable will contain the ID of _one_ of the triggers. +The ID of the Trigger that created the deployment. It is possible for a deployment to be triggered due to multiple triggers. In this case, the variable will contain the ID of *one* of the triggers. Example: *ProjectTriggers-522* `Octopus.Deployment.Trigger.Name` -The name of the Trigger that created the deployment. It is possible for a deployment to be triggered due to multiple triggers. In this case, the variable will contain the name of _one_ of the triggers. +The name of the Trigger that created the deployment. It is possible for a deployment to be triggered due to multiple triggers. In this case, the variable will contain the name of *one* of the triggers. -*Nightly Deploy to Dev* +Example: *Nightly Deploy to Dev* `Octopus.Deployment.WorkerLeaseCap` @@ -748,11 +748,12 @@ public class CommitDetails public string Comment { get; set; } } ``` + There is an entry per release and it includes the release notes (**in markdown format**) and the build information for each of the packages in that release. **Example:** The following iterates the changes in the deployment, printing the release version and the issues contained. -``` +```text #{each change in Octopus.Deployment.Changes} #{change.Version} #{each issue in change.WorkItems} @@ -1109,7 +1110,7 @@ Example: *True* The Storage URI of the \*.cspkg file that will be deployed to the Cloud Service. -Example: https://my-storage-account/container/my-cloudservice.web.cspkg +Example: `https://my-storage-account/container/my-cloudservice.web.cspkg` `Octopus.Action.Azure.UseCurrentInstanceCount` @@ -1209,7 +1210,7 @@ Example: *alice* `Octopus.Action[_name_].Output.OctopusAzureCloudServiceDeploymentID` -The ID of the completed Azure Cloud Service deployment. +The ID of the completed Azure Cloud Service deployment. Example: *c9f52da2b00a4313b3b64bb2ad0f409f* @@ -1217,7 +1218,7 @@ Example: *c9f52da2b00a4313b3b64bb2ad0f409f* The Url of the completed Azure Cloud Service deployment. -Example: *http://c9f52da2b00a4313b3b64bb2ad0f409f.cloudapp.net/* +Example: `http://c9f52da2b00a4313b3b64bb2ad0f409f.cloudapp.net/` ## Step @@ -1259,7 +1260,6 @@ 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 Agent-level variables describe the deployment agent or Tentacle on which the deployment is executing. @@ -1316,7 +1316,7 @@ Example: *[https://my-octopus](https://my-octopus)* `Octopus.Web.ServerUri` -The default URL at which the server portal can be accessed, as configured in the **Configuration ➜ Nodes** settings. +The default URL at which the server portal can be accessed, as configured in the **Configuration ➜ Nodes** settings. *[https://my-octopus](https://my-octopus)* @@ -1382,7 +1382,7 @@ Example: *3/13/20 6:23:38 AM +00:00* The branch name if the runbook run was created from a branch -*branch-abc* +Example: *branch-abc* `Octopus.RunbookRun.Git.CommitHash` @@ -1424,7 +1424,7 @@ Example: *RunbookSnapshots-123* The name of the snapshot. -*Snapshot EXAMPLE3* +Example: *Snapshot EXAMPLE3* `Octopus.RunbookSnapshot.Notes` @@ -1480,11 +1480,10 @@ Example: True `OctopusFreeDiskSpaceOverrideInMegaBytes` -The amount (in megabytes) of available free disk space we should check for (overriding the default 500MB), failing the deployment if not enough free disk space is available. +The amount (in megabytes) of available free disk space we should check for (overriding the default 500MB), failing the deployment if not enough free disk space is available. Example: 100 - `OctopusShouldFailDeploymentOnSubstitutionFails` If set to "True", the deployment will fail if any variable substitution fails. This variable was added in Octopus 2025.1.0. @@ -1505,7 +1504,7 @@ Example: False `Octopus.Action.Script.SuppressEnvironmentLogging` -To suppress/disable the environment logging that occurs from script (eg. PowerShell or Bash Script Environment Variables logging). This only suppresses script logging and does not suppress the Octopus or Calamari environment logging. +To suppress/disable the environment logging that occurs from script (eg. PowerShell or Bash Script Environment Variables logging). This only suppresses script logging and does not suppress the Octopus or Calamari environment logging. Example: True @@ -1523,7 +1522,7 @@ Example: True `Octopus.Action.Package.RunScripts` -Set to `false` to prevent scripts inside packages from executing. +Set to `false` to prevent scripts inside packages from executing. Example: True @@ -1548,10 +1547,19 @@ Octopus will run one task at a time for a given concurrency tag. Set the variabl Example: #{Octopus.Deployment.Tenant.Id}/#{Octopus.Project.Id}/#{Octopus.Environment.Id} +### Kubernetes + +`Octopus.Action.Kubernetes.VerboseOutput` + +Set to `True` to log successful output from Kubernetes CLI tools (`kubectl`, `helm`, `aws`, `az`, `gcloud`, etc.) at the Info level instead of Verbose. This is useful when debugging deployments to see the full output of these tools without needing to enable verbose logging for the entire deployment. + +Example: True + ## Older versions {#older-versions} -* `Octopus.Release.Git.BranchName`, `Octopus.Release.Git.CommitHash` and `Octopus.Release.Git.Ref` is available from Octopus Deploy **2021.3** onwards. -* `Octopus.Web.ServerUri` is available from Octopus Deploy **2019.4.0** onwards. -* `Octopus.Deployment.Tenant.Id`, `Octopus.Deployment.Tenant.Name` and `Octopus.Deployment.Tenant.Tags` is available from Octopus Deploy **3.4** onwards. + +- `Octopus.Release.Git.BranchName`, `Octopus.Release.Git.CommitHash` and `Octopus.Release.Git.Ref` is available from Octopus Deploy **2021.3** onwards. +- `Octopus.Web.ServerUri` is available from Octopus Deploy **2019.4.0** onwards. +- `Octopus.Deployment.Tenant.Id`, `Octopus.Deployment.Tenant.Name` and `Octopus.Deployment.Tenant.Tags` is available from Octopus Deploy **3.4** onwards. ## Learn more