From 12f643d362006f43a391ec9915d78dc11196f5ab Mon Sep 17 00:00:00 2001
From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Date: Fri, 2 Sep 2022 13:30:49 +0200
Subject: [PATCH] docs: lazy-load images (#17565)
---
docs/usage/dependency-pinning.md | 4 ++--
docs/usage/getting-started/installing-onboarding.md | 6 +++---
docs/usage/key-concepts/automerge.md | 2 +-
lib/modules/platform/azure/index.md | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index f0bb261f8e..17fdaffe09 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -142,7 +142,7 @@ You can add a package rule in our Renovate configuration to group these together
Since both `yarn` and `npm@5` both support lock files, it's a common question to ask "Why should I pin dependencies if I'm already using a lock file?".
It's a good question!
-
+{ loading=lazy }
Lock files are a great companion to SemVer ranges _or_ pinning dependencies, because these files lock (pin) deeper into your dependency tree than you see in `package.json`.
@@ -158,7 +158,7 @@ If a lock file gets out of sync with its `package.json`, it can no longer be gua
The lock file has only delayed the inevitable problem, and provides much less visibility than `package.json`, because it's not designed to be human readable and is quite dense.
-
+{ loading=lazy }
If the `package.json` has a range, and a new in-range version is released that would break the build, then essentially your `package.json` is in a state of "broken", even if the lock file is still holding things together.
diff --git a/docs/usage/getting-started/installing-onboarding.md b/docs/usage/getting-started/installing-onboarding.md
index 56cd6f9521..bf24fc43af 100644
--- a/docs/usage/getting-started/installing-onboarding.md
+++ b/docs/usage/getting-started/installing-onboarding.md
@@ -17,11 +17,11 @@ Installing/enabling Mend's Renovate GitHub App is simple.
First, navigate to [https://github.com/apps/renovate](https://github.com/apps/renovate) and click the Install button:
-
+{ loading=lazy }
The only choice you need to make is whether to run Renovate on all repositories or on selected repositories:
-
+{ loading=lazy }
Renovate will ignore any repositories that don't have known package files, as well as any forks, so you can enable Renovate for all your repositories with no problems.
That said, most people run Renovate on selected repositories.
@@ -55,7 +55,7 @@ You can also set the line endings in your repository by adding `* text=auto eol=
Once you have enabled Renovate on a repository, you will get a "Configure Renovate" Pull Request looking something like this:
-
+{ loading=lazy }
### No risk onboarding
diff --git a/docs/usage/key-concepts/automerge.md b/docs/usage/key-concepts/automerge.md
index adebe6c13c..2fda03afbc 100644
--- a/docs/usage/key-concepts/automerge.md
+++ b/docs/usage/key-concepts/automerge.md
@@ -27,7 +27,7 @@ For example, if you have Jest or Mocha as a development dependency, and it has a
If you have a linter like ESLint or TSLint and its update passes... automerge them!
If you have an API with 100% test coverage and Express is updated... automerge it!
-
+{ loading=lazy }
## Configuration examples
diff --git a/lib/modules/platform/azure/index.md b/lib/modules/platform/azure/index.md
index d1b3c8a075..b9e5557e87 100644
--- a/lib/modules/platform/azure/index.md
+++ b/lib/modules/platform/azure/index.md
@@ -20,12 +20,12 @@ Remember to set `platform=azure` somewhere in your Renovate config file.
### Setting up a new pipeline
Create a brand new pipeline within Azure DevOps, and select your source:
-
+{ loading=lazy }
Then select your repository.
Within _Configure your pipeline_ select: **Starter pipeline**
-
+{ loading=lazy }
Replace _all_ content in the starter pipeline with:
--
GitLab