From a7903a4de2843ccb1537699aeedb8e3b458ec7cc Mon Sep 17 00:00:00 2001
From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Date: Mon, 7 Feb 2022 15:53:22 +0100
Subject: [PATCH] docs: replace receive with get (#14073)
---
docs/development/adding-a-package-manager.md | 2 +-
docs/development/design-decisions.md | 2 +-
docs/usage/configuration-options.md | 10 +++++-----
docs/usage/dependency-pinning.md | 8 ++++----
docs/usage/docker.md | 4 ++--
docs/usage/getting-started/installing-onboarding.md | 4 ++--
docs/usage/key-concepts/scheduling.md | 2 +-
lib/manager/terragrunt/readme.md | 2 +-
lib/platform/bitbucket-server/index.md | 2 +-
readme.md | 2 +-
10 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/docs/development/adding-a-package-manager.md b/docs/development/adding-a-package-manager.md
index f13764d57c..622d8d8ed2 100644
--- a/docs/development/adding-a-package-manager.md
+++ b/docs/development/adding-a-package-manager.md
@@ -31,7 +31,7 @@ The function returns an array of detected/extracted dependencies, including:
- currentValue
- versioning used (e.g. SemVer, PEP 440)
-The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it receives.
+The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it gets.
It needs to understand enough to extract an accurate list of dependencies.
As a general approach, we extract _all_ dependencies from each dependency file, even if they contain values we don't support.
diff --git a/docs/development/design-decisions.md b/docs/development/design-decisions.md
index 2df2c70c71..79b0dc69c1 100644
--- a/docs/development/design-decisions.md
+++ b/docs/development/design-decisions.md
@@ -73,7 +73,7 @@ Branches have names like `renovate/webpack-1.x` instead of `renovate/webpack-1.2
We do this because:
-- Branches often receive updates (e.g. new patches) before they're merged
+- Branches often get updates (e.g. new patches) before they're merged
- Naming the branch like `1.x` means its name still makes sense if a `1.2.1` release happens
Note: You can configure the branch names by using the string template `branchName` and/or its sub-templates `branchPrefix` and `branchTopic`.
diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
index a0d4172651..d1e0db27ba 100644
--- a/docs/usage/configuration-options.md
+++ b/docs/usage/configuration-options.md
@@ -1011,7 +1011,7 @@ To abort Renovate for errors for a specific `docker` host:
}
```
-When this field is enabled, Renovate will abort its run if it encounters either (a) any low-level http error (e.g. `ETIMEDOUT`) or (b) receives a response _not_ matching any of the configured `abortIgnoreStatusCodes` (e.g. `500 Internal Error`);
+When this field is enabled, Renovate will abort its run if it encounters either (a) any low-level http error (e.g. `ETIMEDOUT`) or (b) gets a response _not_ matching any of the configured `abortIgnoreStatusCodes` (e.g. `500 Internal Error`);
### authType
@@ -1973,7 +1973,7 @@ Your test suite takes a bit of time to complete, so if you go look at the new PR
You're basically waiting until you have the test results, before you can decide if you want to merge the PR or not.
With prCreation set to `not-pending`, Renovate waits until all tests have finished running, and only then creates the PR.
-When you receive the PR notification, you can take action immediately, as you have the full test results.
+When you get the PR notification, you can take action immediately, as you have the full test results.
When you set prCreation to `not-pending` you're reducing the "noise" but get notified of new PRs a bit later.
@@ -2535,7 +2535,7 @@ If instead you applied the 3.0.0 update then Renovate would clean up the unneede
It is recommended that you leave this option to `true`, because of the polite way that Renovate handles this.
For example, let's say in the above example that you decided you wouldn't update to Webpack 3 for a long time and don't want to build/test every time a new 3.x version arrives.
In that case, simply close the "Update Webpack to version 3.x" PR and it _won't_ be recreated again even if subsequent Webpack 3.x versions are released.
-You can continue with Webpack 2.x for as long as you want and receive any updates/patches that are made for it.
+You can continue with Webpack 2.x for as long as you want and get any updates/patches that are made for it.
Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to the base branch once it's tested.
After that, Renovate will resume providing you updates to 3.x again!
i.e. if you close a major upgrade PR then it won't come back again, but once you make the major upgrade yourself then Renovate will resume providing you with minor or patch updates.
@@ -2552,7 +2552,7 @@ If you wish to distinguish between patch and minor upgrades, for example if you
## separateMultipleMajor
-Configure this to `true` if you wish to receive one PR for every separate major version upgrade of a dependency.
+Configure this to `true` if you wish to get one PR for every separate major version upgrade of a dependency.
e.g. if you are on webpack@v1 currently then default behavior is a PR for upgrading to webpack@v3 and not for webpack@v2.
If this setting is true then you would get one PR for webpack@v2 and one for webpack@v3.
@@ -2715,7 +2715,7 @@ For this to work, you must first ensure you have enabled "[Dependency graph](htt
Additionally, if you are running Renovate in app mode then you must make sure that the app has been granted the permissions to read "Vulnerability alerts".
If you are the account admin, browse to the app (e.g. [https://github.com/apps/renovate](https://github.com/apps/renovate)), select "Configure", and then scroll down to the "Permissions" section and verify that read access to "vulnerability alerts" is mentioned.
-Once the above conditions are met, and you have received one or more vulnerability alerts from GitHub for this repository, then Renovate will attempt to raise fix PRs accordingly.
+Once the above conditions are met, and you got one or more vulnerability alerts from GitHub for this repository, then Renovate will attempt to raise fix PRs accordingly.
Use the `vulnerabilityAlerts` configuration object if you want to customise vulnerability-fix PRs specifically.
For example, to configure custom labels and assignees:
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index 5675c1e615..20cdd3b33f 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -75,7 +75,7 @@ This is more common and more dangerous.
If you were using SemVer ranges then this new version of `foobar` will likely be deployed to production automatically one day, sometime after which you notice errors and realise you need to fix it.
Like before, you need to manually work out which dependency caused it - assuming you guess correctly that it was a new dependency version at fault - and pin it manually by editing `package.json` one dependency at a time.
-Alternatively, if you were instead pinning `foobar` then you would receive a PR for `foobar@1.2.0` which awaits your approval.
+Alternatively, if you were instead pinning `foobar` then you would get a PR for `foobar@1.2.0` which awaits your approval.
So first of all, you can choose to read the release notes and/or visually inspect the branch yourself before merging, hopefully saving you from pushing this faulty code to production.
If you did not catch the fault before merging, you are still better off with a pinned version.
@@ -88,7 +88,7 @@ As you can see in the above, pinning dependencies makes your build more consiste
### Downside of pinned dependencies - upgrade "noise"
The one major downside to your development workflow of pinning dependencies is the potential for increased "noise" in your repository.
-As mentioned above, you can expect to receive Pull Requests whenever there is a new version of your dependencies available.
+As mentioned above, you can expect to get Pull Requests whenever there is a new version of your dependencies available.
Depending on how many repositories you maintain, and how many dependencies are in each, you may find this default approach to be overwhelming (e.g. waking up to 10 new Pull Requests each day).
## Reducing the "noise" of dependency updates
@@ -109,7 +109,7 @@ In that case if the `pg` package has a minor or patch update and passes all test
### Branch automerging
-In the above suggestion of Pull Request automerging, you might still find it annoying if you receive GitHub Notifications for every PR that is created and merged.
+In the above suggestion of Pull Request automerging, you might still find it annoying if you get GitHub Notifications for every PR that is created and merged.
In that case, you could set `automergeType` to `branch`, which means Renovate will:
- Create a new branch for testing
@@ -121,7 +121,7 @@ With this approach, updates will be essentially "silent" - causing no notificati
### Scheduling
-Although it can feel satisfying to receive updates "immediately" when they're available, the reality is that you usually don't _need_ updates so frequently.
+Although it can feel satisfying to get updates "immediately" when they're available, the reality is that you usually don't _need_ updates so frequently.
And worse still, npm package versions that are less than 24 hours [can be unpublished](https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy), which would really break your build if you've pinned to a version that no longer exists.
So to reduce the interruptions of automated dependency updates, consider putting Renovate on a schedule, such as:
diff --git a/docs/usage/docker.md b/docs/usage/docker.md
index 5849775303..14eb179cfa 100644
--- a/docs/usage/docker.md
+++ b/docs/usage/docker.md
@@ -93,13 +93,13 @@ Read on to see how Renovate updates Docker digests.
## Digest Updating
-If you follow our advice to go from a simple tag like `node:14` to using a pinned digest `node:14@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e`, you will receive Renovate PRs whenever the `node:14` image is updated on Docker Hub.
+If you follow our advice to go from a simple tag like `node:14` to using a pinned digest `node:14@sha256:d938c1761e3afbae9242848ffbb95b9cc1cb0a24d889f8bd955204d347a7266e`, you will get Renovate PRs whenever the `node:14` image is updated on Docker Hub.
Previously this update would have been "invisible" to you - one day you pull code that represents `node:14.15.0` and the next day you get code that represents `node:14.15.1`.
But you can never be sure, especially as Docker caches.
Perhaps some of your colleagues or worse still your build machine are stuck on an older version with a security vulnerability.
-By pinning to a digest instead, you will receive these updates via Pull Requests, or even committed directly to your repository if you enable branch automerge for convenience.
+By pinning to a digest instead, you will get these updates via Pull Requests, or even committed directly to your repository if you enable branch automerge for convenience.
This ensures everyone on the team uses the latest versions and is in sync.
## Version Upgrading
diff --git a/docs/usage/getting-started/installing-onboarding.md b/docs/usage/getting-started/installing-onboarding.md
index 9b46b917a5..26f3d81cc9 100644
--- a/docs/usage/getting-started/installing-onboarding.md
+++ b/docs/usage/getting-started/installing-onboarding.md
@@ -41,7 +41,7 @@ For more details on GitLab security for bots, please see the [GitLab Bot Securit
## Repository onboarding
-Once you have enabled Renovate on a repository, you will receive a "Configure Renovate" Pull Request looking something like this:
+Once you have enabled Renovate on a repository, you will get a "Configure Renovate" Pull Request looking something like this:
@@ -134,4 +134,4 @@ Any existing Renovate PRs will be closed after you've completed these steps.
1. Remove the current Renovate configuration file (e.g. `renovate.json`) from your mainline branch
Following these steps will trick Renovate into thinking that your repository was _never_ onboarded, and will trigger a new "Configure Renovate" PR.
-If you're using the hosted WhiteSource Renovate App and you don't receive a new onboarding PR within a few hours, then please create a Discussions post to request staff trigger it manually.
+If you're using the hosted WhiteSource Renovate App and you don't get a new onboarding PR within a few hours, then please create a Discussions post to request staff trigger it manually.
diff --git a/docs/usage/key-concepts/scheduling.md b/docs/usage/key-concepts/scheduling.md
index 579b76a306..7eabf25657 100644
--- a/docs/usage/key-concepts/scheduling.md
+++ b/docs/usage/key-concepts/scheduling.md
@@ -8,7 +8,7 @@ This document describes Renovate's scheduling.
## Default behavior
By default, Renovate bot runs as often as its administrator has configured it to (e.g. hourly, daily, etc.).
-The exact frequency at which Renovate can process individual repositories depends on the combination of how often it runs, how many repositories are installed, and whether there's a lot of work to be done in each repository (e.g. if a commonly used dependency has recently received a new update, which triggers a lot of PRs to be created).
+The exact frequency at which Renovate can process individual repositories depends on the combination of how often it runs, how many repositories are installed, and whether there's a lot of work to be done in each repository (e.g. if a commonly used dependency has recently gotten a new update, which triggers a lot of PRs to be created).
By default, Renovate schedules use the UTC timezone.
You can override the default timezone by setting your own `timezone` config option.
diff --git a/lib/manager/terragrunt/readme.md b/lib/manager/terragrunt/readme.md
index 5c1c9d63a2..7ed995cc50 100644
--- a/lib/manager/terragrunt/readme.md
+++ b/lib/manager/terragrunt/readme.md
@@ -11,7 +11,7 @@ For example, if you want to reference a tag like `module-v1.2.5`, a block like t
}
```
-Pinned Terragrunt dependencies like the following will receive a PR whenever there is a newer version available:
+Pinned Terragrunt dependencies like the following will get a PR whenever there is a newer version available:
```hcl
terraform {
diff --git a/lib/platform/bitbucket-server/index.md b/lib/platform/bitbucket-server/index.md
index ffd56859d7..813bf51fec 100644
--- a/lib/platform/bitbucket-server/index.md
+++ b/lib/platform/bitbucket-server/index.md
@@ -47,7 +47,7 @@ export LOG_LEVEL=debug
yarn start --autodiscover=true
```
-You should then receive a "Configure Renovate" onboarding PR in any projects that `@renovate-bot` has been invited to.
+You should then get a "Configure Renovate" onboarding PR in any projects that `@renovate-bot` has been invited to.
## Supported versions
diff --git a/readme.md b/readme.md
index 4aaee96c05..71533fa7ba 100644
--- a/readme.md
+++ b/readme.md
@@ -12,7 +12,7 @@ Multi-platform and multi-language.
## Why Use Renovate?
-- Receive automated Pull Requests whenever dependencies need updating
+- Get automated Pull Requests whenever dependencies need updating
- Define schedules to avoid unnecessary noise in projects (e.g. for weekends or outside of working hours, or weekly updates, etc.)
- Relevant package files are discovered automatically (e.g. supports monorepo architecture such as Lerna or Yarn workspaces without further configuration)
- Bot behavior is extremely customizable via configuration files (config as code)
--
GitLab