#2964 fix markdown linting errors

Author: arturcic

.remarkrc.yaml

@@ -25,12 +25,12 @@ plugins:
   - remark-lint-no-blockquote-without-marker
   - remark-lint-no-consecutive-blank-lines
   - remark-lint-no-duplicate-definitions
-  - remark-lint-no-duplicate-headings
+  - remark-lint-no-duplicate-headings: ["warn"]
   - remark-lint-no-emphasis-as-heading
   - remark-lint-no-empty-url
   - remark-lint-no-file-name-articles
   - remark-lint-no-file-name-consecutive-dashes
-  - remark-lint-no-file-name-irregular-characters
+  - remark-lint-no-file-name-irregular-characters: ["warn"]
   - remark-lint-no-file-name-mixed-case
   - remark-lint-no-file-name-outer-dashes
   - remark-lint-no-heading-content-indent

README.md

@@ -14,7 +14,7 @@ works out the [Semantic Version][semver] of the commit being built.
 | **GitVersion.Portable**    |                     [![Chocolatey][choco-badge]][choco]            |
 | **GitVersion.Tool**        |                           [![NuGet][gvgt-badge]][gvgt]             |
 | **GitVersion.CommandLine** |                           [![NuGet][gvcl-badge]][gvcl]             |
-| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as [GitVersionTask] before v5.6.0 |
+| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as [GitVersionTask][gitversiontask] before v5.6.0 |
 | **Homebrew**               |                        [![homebrew][brew-badge]][brew]             |
 | **Azure Pipeline Task**    | [![Azure Pipeline Task][az-pipeline-task-badge]][az-pipeline-task] |
 | **Github Action**          |             [![Github Action][gh-actions-badge]][gh-actions]       |

SECURITY.md

@@ -17,13 +17,13 @@ You should receive a response within 24 hours. If for some reason you do not, pl
 
 Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
 
-  * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
-  * Full paths of source file(s) related to the manifestation of the issue
-  * The location of the affected source code (tag/branch/commit or direct URL)
-  * Any special configuration required to reproduce the issue
-  * Step-by-step instructions to reproduce the issue
-  * Proof-of-concept or exploit code (if possible)
-  * Impact of the issue, including how an attacker might exploit the issue
+*   Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
+*   Full paths of source file(s) related to the manifestation of the issue
+*   The location of the affected source code (tag/branch/commit or direct URL)
+*   Any special configuration required to reproduce the issue
+*   Step-by-step instructions to reproduce the issue
+*   Proof-of-concept or exploit code (if possible)
+*   Impact of the issue, including how an attacker might exploit the issue
 
 This information will help us triage your report more quickly.
 

build/nuspec/README.md

@@ -9,7 +9,7 @@ works out the [Semantic Version][semver] of the commit being built.
 | :------------------------- | :----------------------------------------------------------------- | - |
 | **GitVersion.Tool**        |                           [![NuGet][gvgt-badge]][gvgt]             |
 | **GitVersion.CommandLine** |                           [![NuGet][gvcl-badge]][gvcl]             |
-| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as [GitVersionTask] before v5.6.0 |
+| **GitVersion.MsBuild**     |                            [![NuGet][gvt-badge]][gvt]              | Known as [GitVersionTask][gitversiontask] before v5.6.0 |
 
 ## Compatibility
 
@@ -44,8 +44,6 @@ from The Noun Project.
 [gitter]:                          https://gitter.im/GitTools/GitVersion?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
 [gitter-badge]:                    https://badges.gitter.im/Join+Chat.svg
 [docs]:                            https://gitversion.net/docs/
-[gh-rel]:                          https://github.com/GitTools/GitVersion/releases/latest
-[gh-rel-badge]:                    https://img.shields.io/github/release/gittools/gitversion.svg?logo=github
 [gvt]:                             https://www.nuget.org/packages/GitVersion.MsBuild
 [gvt-badge]:                       https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
 [gitversiontask]:                  https://www.nuget.org/packages/GitVersionTask/

docs/input/docs/learn/branching-strategies/gitflow/index.md

@@ -8,8 +8,6 @@ RedirectFrom: docs/git-branching-strategies/gitflow
 Git Flow allows more structured releases, and GitVersion will derive sensible
 SemVer compatible versions from this structure.
 
-## Resources
-
 ## Assumptions:
 
 *   Using [GitFlow branching model](https://nvie.com/git-model/) which always has a
@@ -58,7 +56,7 @@ Optional Tags (only when transitioning existing repository):
 
 Long version:
 
-```
+```txt
 {major}.{minor}.{patch} Sha:'{sha}'
 1.2.3 Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 ```
@@ -78,7 +76,7 @@ Long version:
 
 Long version:
 
-```
+```txt
 {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
 1.2.3-alpha.645 Branch:'develop' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 ```
@@ -97,7 +95,7 @@ Named: `hotfix-{versionNumber}` eg `hotfix-1.2`
 
 Long version:
 
-```
+```txt
 {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
 1.2.3-beta645 Branch:'hotfix-foo' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 ```
@@ -125,7 +123,7 @@ that tag the version would be `1.2.0-alpha1.4`
 
 Long version:
 
-```
+```txt
 {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
 1.2.3-alpha2.4 Branch:'release-1.2' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 1.2.3-rc2 Branch:'release-1.2' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
@@ -149,7 +147,7 @@ branches named like "4.0.3"
 
 Long version:
 
-```
+```txt
 {major}.{minor}.{patch}-{pre-release} Branch:'{branchName}' Sha:'{sha}'
 1.2.3-alpha.feature-a682956d Branch:'feature1' Sha:'a682956dccae752aa24597a0f5cd939f93614509'
 ```

docs/input/docs/learn/credits.md

@@ -9,13 +9,13 @@ Icons sourced, with love, from [The Noun Project][the-noun-project]:
 |                     Icon                    | Designer                                                   |
 | :-----------------------------------------: | :--------------------------------------------------------- |
 |       [![Tree][tree-icon]][tree-link]       | [Tree][tree-link] by [Davic Chapman][david-chapman]        |
-|    [![Repeat][repeat-icon]][repeat-link]    | [Repeat][repeat-link] by [Arthur Shlain][artZ91]           |
-| [![Terminal][terminal-icon]][terminal-link] | [Terminal][terminal-link] by [Ghayn]                       |
+|    [![Repeat][repeat-icon]][repeat-link]    | [Repeat][repeat-link] by [Arthur Shlain][artz91]           |
+| [![Terminal][terminal-icon]][terminal-link] | [Terminal][terminal-link] by [Ghayn][ghayn]                |
 |   [![Collect][collect-icon]][collect-link]  | [Collect][collect-link] by [Shmidt Sergey][monstercritic]  |
 |   [![Library][library-icon]][library-link]  | [Library][library-link] by [Kevin Eichhorn][kevineichhorn] |
 :::
 
-[artZ91]: https://thenounproject.com/ArtZ91/
+[artz91]: https://thenounproject.com/ArtZ91/
 [collect-icon]: /assets/img/collect.svg
 [collect-link]: https://thenounproject.com/term/collect/424422/
 [david-chapman]: https://thenounproject.com/david.chapman/

docs/input/docs/learn/faq.md

@@ -30,7 +30,7 @@ be a good primer to read before reading [SemVer.org][semver].
 ## I can't use the build number for NuGet
 
 If you have used NuGet you would notice the versions above are not compatible
-with NuGet. GitVersion solves this by providing [variables].
+with NuGet. GitVersion solves this by providing [variables][variables].
 
 What you have seen above is the `SemVer` variable. You can use the
 `NuGetVersion` variable to have the version formatted in a NuGet compatible way.

docs/input/docs/reference/build-servers/gitlab.md

@@ -9,25 +9,26 @@ To use GitVersion with GitLab CI, either use the [MSBuild
 Task](/docs/usage/msbuild) or put the GitVersion executable in your
 runner's `PATH`.
 
-A working example of integrating GitVersion with GitLab is maintained in the project [Utterly Automated Software and Artifact Versioning with GitVersion][]
+A working example of integrating GitVersion with GitLab is maintained in the project [Utterly Automated Versioning][utterly-automated-versioning]
 
-Here is a summary of what it demonstrated (many more details in the [README.md][])
+Here is a summary of what it demonstrated (many more details in the [Readme][readme])
 
-- Is a reusable working example known as a Guided Exploration ([GE Manifesto][]) - so job logs and package artifacts can be reviewed. The project can also be imported to your own GitLab group or instance as a starting point for your own work.
-- IMPORTANT: It demonstrates how to override GitLab CI's default cloning behavior so that GitVersion can do a dynamic copy. Selectively clones GitVersion.yml so that these settings take effect. This best practice demonstrates the best way to do this while avoiding a double-cloning of the project (once by GitLab Runner and once by GitVersion). 
-- Implements GitVersion as a CI/CD Extension that can be reused across many projects using includes.
-- Implements GitVersion as a single job that runs the GitVersion container and passes the version number downstream into both _pipeline_ and _job_ level variables, which means...
-- It can be used with ANY coding language, framework or packaging engine.
-- Generates example packaged artifacts:
-  - Two ways of building Sem Versioned NuGet packages (msbuild-ish and nuget.exe-ish) and uploads them and tests them from a [GitLab NuGet repository][].
-  - A Sem Versioned [GitLab Generic Package][]
-  - A Sem Versioned docker container and uploads to [GitLabs Container Registry][].
-- It creates a Sem Versioned [GitLab Release](GitLab Releases Feature Help) and Git tag using the [GitLab release-cli][] and links the generic package as evidence.
+-   Is a reusable working example known as a Guided Exploration ([Guided Exploration Manifesto][guided-exploration-manifesto]) - so job logs and package artifacts can be reviewed. The project can also be imported to your own GitLab group or instance as a starting point for your own work.
+-   IMPORTANT: It demonstrates how to override GitLab CI's default cloning behavior so that GitVersion can do a dynamic copy. Selectively clones GitVersion.yml so that these settings take effect. This best practice demonstrates the best way to do this while avoiding a double-cloning of the project (once by GitLab Runner and once by GitVersion).
+-   Implements GitVersion as a CI/CD Extension that can be reused across many projects using includes.
+-   Implements GitVersion as a single job that runs the GitVersion container and passes the version number downstream into both _pipeline_ and _job_ level variables, which means...
+-   It can be used with ANY coding language, framework or packaging engine.
+-   Generates example packaged artifacts:
+    -   Two ways of building Sem Versioned NuGet packages (msbuild-ish and nuget.exe-ish) and uploads them and tests them from a [GitLab NuGet Repository][gitlab-nuget-repository].
+    -   A Sem Versioned [GitLab Generic Package][gitlab-generic-package]
+    -   A Sem Versioned docker container and uploads to [GitLab Container Registry][gitlab-container-registry].
+-   It creates a Sem Versioned [GitLab Release][gitlab-release-help] and Git tag using the [GitLab Release Cli][gitlab-release-cli] and links the generic package as evidence.
 
-[GitLab Generic Package]: https://docs.gitlab.com/ee/user/packages/generic_packages/
-[GitLab NuGet repository]: https://docs.gitlab.com/ee/user/packages/nuget_repository/
-[GitLab release-cli]: https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs
-[GitLabs Container Registry]: https://docs.gitlab.com/ee/user/packages/container_registry/
-[GE Manifesto]: https://gitlab.com/guided-explorations/guided-exploration-concept/-/blob/master/README.md
-[README.md]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/-/blob/develop/README.md
-[Utterly Automated Software and Artifact Versioning with GitVersion]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/
+[gitlab-generic-package]: https://docs.gitlab.com/ee/user/packages/generic_packages/
+[gitlab-nuget-repository]: https://docs.gitlab.com/ee/user/packages/nuget_repository/
+[gitlab-release-cli]: https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs
+[gitlab-container-registry]: https://docs.gitlab.com/ee/user/packages/container_registry/
+[guided-exploration-manifesto]: https://gitlab.com/guided-explorations/guided-exploration-concept/-/blob/master/README.md
+[readme]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/-/blob/develop/README.md
+[utterly-automated-versioning]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/
+[gitlab-release-help]: https://docs.gitlab.com/ee/user/project/releases/

docs/input/docs/reference/build-servers/jenkins.md

@@ -25,10 +25,10 @@ Integrating GitVersion into your Jenkins build varies based on the project type:
 
 Injecting environment variables is not supported in Jenkins natively, but
 Jenkins plugins exist that provide this functionality. Of these plugins
-[EnvInject] appears to be the most popular with over 20k downloads per month.
+[EnvInject][env-inject] appears to be the most popular with over 20k downloads per month.
 
 To inject the GitVersion variables as environment variables for a build job
-using [EnvInject], do the following:
+using [EnvInject][env-inject], do the following:
 
 1.  Add an **Execute Windows batch command** build step with _Command_:
     `gitversion /output buildserver`
@@ -51,7 +51,7 @@ You can verify correct injection of environment variables by adding another
 
 ### Pipeline Projects
 
-For pipeline projects, GitVersion variables can be accessed by reading the `gitversion.properties` file using the [Pipeline Utility Steps] plugin. Variables from a property file are not automatically merged with the environment variables, but they can be accessed within a script block.
+For pipeline projects, GitVersion variables can be accessed by reading the `gitversion.properties` file using the [Pipeline Utility Steps][pipeline-utility-steps] plugin. Variables from a property file are not automatically merged with the environment variables, but they can be accessed within a script block.
 
 In a pipeline stage:
 
@@ -75,5 +75,5 @@ script {
 }
 ```
 
-[EnvInject]: https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
-[Pipeline Utility Steps]: https://plugins.jenkins.io/pipeline-utility-steps
+[env-inject]: https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
+[pipeline-utility-steps]: https://plugins.jenkins.io/pipeline-utility-steps

docs/input/docs/reference/build-servers/teamcity.md

@@ -7,7 +7,7 @@ RedirectFrom: docs/build-server-support/build-server/teamcity
 
 ## Basic Usage
 
-In [TeamCity] you can create a build step as follows:
+In [TeamCity][teamcity] you can create a build step as follows:
 
 *   **Runner type:** Command Line
 *   **Run:** Executable with parameters
@@ -26,7 +26,6 @@ TeamCity has support for meta-runners which allow custom tasks. There is a
 [GitVersion meta-runner][meta-runner] available which makes it easy to use
 GitVersion.
 
-
 ## Running inside TeamCity
 
 When running in TeamCity you have two options, run using **agent checkout** or
@@ -70,7 +69,7 @@ See [dynamic repositories][dynamic-repo] for more info.
 
 ### NuGet in TeamCity
 
-*   Add a dummy [parameter] to the project called `GitVersion.NuGetVersion`. If
+*   Add a dummy [parameter][parameter] to the project called `GitVersion.NuGetVersion`. If
     many of your projects uses git-flow and SemVer you can add the parameter to
     the "root-project" (TeamCity 8.x+). You need a dummy param because
     GitVersion creates the variables at runtime, and you cannot reference a

docs/input/docs/reference/configuration.md

@@ -32,7 +32,7 @@ To see the effective configuration (defaults and overrides), you can run
 `gitversion /showConfig`.
 
 To create your config file just type `gitversion init` in your repo directory,
-after [installing]. A minimal `GitVersion.yml` configuration file will be
+after [installing][installing]. A minimal `GitVersion.yml` configuration file will be
 created. Modify this to suit your needs.
 
 ## Global configuration
@@ -103,7 +103,7 @@ skip updating the `AssemblyFileVersion` while still updating the
 Specifies the format of `AssemblyFileVersion` and
 overwrites the value of `assembly-file-versioning-scheme`.
 
-Expressions in curly braces reference one of the [variables]
+Expressions in curly braces reference one of the [variables][variables]
 or a process-scoped environment variable (when prefixed with `env:`).  For example,
 
 ```yaml
@@ -281,9 +281,9 @@ merge-message-formats:
 
 The regular expression should contain the following capture groups:
 
-* `SourceBranch` - Identifies the source branch of the merge
-* `TargetBranch` - Identifies the target branch of the merge
-* `PullRequestNumber` - Captures the pull-request number
+*   `SourceBranch` - Identifies the source branch of the merge
+*   `TargetBranch` - Identifies the target branch of the merge
+*   `PullRequestNumber` - Captures the pull-request number
 
 Custom merge message formats are evaluated _before_ any built in formats.
 Support for [Conventional Commits][conventional-commits] can be
@@ -424,16 +424,16 @@ Take this commit graph
 
 By looking at this graph, you cannot tell which of these scenarios happened:
 
-* feature/foo branches off release/v1.0.0
-  * Branch release/v1.0.0 from main
-  * Branch feature/foo from release/v1.0.0
-  * Add a commit to both release/v1.0.0 and feature/foo
-  * release/v1.0.0 is the base for feature/foo
-* release/v1.0.0 branches off feature/foo
-  * Branch feature/foo from main
-  * Branch release/v1.0.0 from feature/foo
-  * Add a commit to both release/v1.0.0 and feature/foo
-  * feature/foo is the base for release/v1.0.0
+*   feature/foo branches off release/v1.0.0
+    *   Branch release/v1.0.0 from main
+    *   Branch feature/foo from release/v1.0.0
+    *   Add a commit to both release/v1.0.0 and feature/foo
+    *   release/v1.0.0 is the base for feature/foo
+*   release/v1.0.0 branches off feature/foo
+    *   Branch feature/foo from main
+    *   Branch release/v1.0.0 from feature/foo
+    *   Add a commit to both release/v1.0.0 and feature/foo
+    *   feature/foo is the base for release/v1.0.0
 
 Or put more simply, you cannot tell which branch was created first,
 `release/v1.0.0` or `feature/foo`.
@@ -560,7 +560,7 @@ default `main` and `support/*` are mainlines.
 
 ### pre-release-weight
 
-Provides a way to translate the `PreReleaseLabel` ([variables]) to a numeric
+Provides a way to translate the `PreReleaseLabel` ([variables][variables]) to a numeric
 value in order to avoid version collisions across different branches. For
 example, a release branch created after "1.2.3-alpha.55" results in
 "1.2.3-beta.1" and thus e.g. "1.2.3-alpha.4" and "1.2.3-beta.4" would have the
@@ -569,8 +569,8 @@ same file version: "1.2.3.4". One of the ways to use this value is to set
 {Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber}`. If the `pre-release-weight`
 is set, it would be added to the `PreReleaseNumber` to get a final
 `AssemblySemFileVer`, otherwise a branch specific default for
-`pre-release-weight` will be used in the calculation. Related Issues [1145]
-and [1366].
+`pre-release-weight` will be used in the calculation. Related Issues [1145][1145]
+and [1366][1366].
 
 [1145]: https://github.com/GitTools/GitVersion/issues/1145
 [1366]: https://github.com/GitTools/GitVersion/issues/1366

docs/input/docs/reference/modes/continuous-delivery.md

@@ -42,7 +42,7 @@ to deploy to production at any time.
 By default, GitVersion is set up to do Continuous Delivery on all branches but
 `develop`, which is set up with [Continuous Deployment][continuous-deployment].
 To change the mode to Continuous Delivery, change your
-[configuration] to:
+[configuration][configuration] to:
 
 ```yaml
 mode: ContinuousDelivery