From 06ff972ed0fd834019eab67b56f21a990c2f3cea Mon Sep 17 00:00:00 2001 From: Juliet Boyd <5061312+julietrb1@users.noreply.github.com> Date: Wed, 26 Nov 2025 11:17:37 +1100 Subject: [PATCH] Replace "lets" with "let's" --- .../high-availability/how-high-availability-works.md | 2 +- .../troubleshooting-integrations-with-build-servers.md | 2 +- .../variable-filters-in-octostache-conditionals.include.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/pages/docs/administration/high-availability/how-high-availability-works.md b/src/pages/docs/administration/high-availability/how-high-availability-works.md index ba927ef6cf..d311352fd1 100644 --- a/src/pages/docs/administration/high-availability/how-high-availability-works.md +++ b/src/pages/docs/administration/high-availability/how-high-availability-works.md @@ -53,7 +53,7 @@ A node will not pick up pending tasks when: The last item in that list needs a deeper dive to understand. For this example, we have a cluster with three nodes, each with a task cap set to ten (10). Thus, making the HA cluster's total task capacity 30. There are 12 pending tasks in the queue and 10 active tasks. -Lets assume all three nodes check the task queue at the same time. The prospective cluster workload ratio is **73.34%** (12 pending tasks + 10 active tasks / 30 task capacity). +Let's assume all three nodes check the task queue at the same time. The prospective cluster workload ratio is **73.34%** (12 pending tasks + 10 active tasks / 30 task capacity). - One node is currently processing eight tasks making the current node workload ratio **80%** (8/10). While this node can pick up two more tasks, it will not because **80%** > **73.34%**. - One node is currently processing three tasks making the current node workload ratio **30%** (3/10). It can pick up seven more tasks but will only pick up five more tasks. It picks up tasks until its current node workload ratio is greater than the prospective cluster workload ratio. diff --git a/src/pages/docs/packaging-applications/build-servers/troubleshooting-integrations-with-build-servers.md b/src/pages/docs/packaging-applications/build-servers/troubleshooting-integrations-with-build-servers.md index cd9df9c8ca..88052686e4 100644 --- a/src/pages/docs/packaging-applications/build-servers/troubleshooting-integrations-with-build-servers.md +++ b/src/pages/docs/packaging-applications/build-servers/troubleshooting-integrations-with-build-servers.md @@ -19,7 +19,7 @@ If you are reading this doc, odds are you already tried to run an Octopus-relate The Octopus Deploy team supports many of the most popular integration plugins/extensions our there, like the ones for [Azure DevOps/TFS](/docs/packaging-applications/build-servers/tfs-azure-devops/), [Teamcity](/docs/packaging-applications/build-servers/teamcity/) and [Bamboo](/docs/packaging-applications/build-servers/bamboo). All the steps provided by these extensions/plugins are nothing but wrappers of the Octopus CLI that provide a UI with fields whose values will be passed to this command line tool during the build. -Lets take for example this TeamCity **Octopus Deploy: Create Release** step: +Let's take for example this TeamCity **Octopus Deploy: Create Release** step: :::figure ![](/docs/img/packaging-applications/build-servers/images/5672462.png) diff --git a/src/shared-content/projects/deployment-process/variable-filters-in-octostache-conditionals.include.md b/src/shared-content/projects/deployment-process/variable-filters-in-octostache-conditionals.include.md index cd25af8e5b..f8d11b0e2d 100644 --- a/src/shared-content/projects/deployment-process/variable-filters-in-octostache-conditionals.include.md +++ b/src/shared-content/projects/deployment-process/variable-filters-in-octostache-conditionals.include.md @@ -11,7 +11,7 @@ If you wanted to include a variable run condition to run a step *only* when the ``` However, the evaluation of the statement would always return `False` as the syntax is not supported. -Instead you need to create a variable that includes the variable filter you want to use. For this example, lets assume it's named `PreReleaseBranch` with the value: +Instead you need to create a variable that includes the variable filter you want to use. For this example, let's assume it's named `PreReleaseBranch` with the value: ``` #{Octopus.Release.Number | VersionPreReleasePrefix}