Markdown linting: build steps and last fixes (#5345)

* add linting config files

* fix some trailing spaces

* trailing spaces

* add build step

.markdownlint.json

@@ -0,0 +1,9 @@
+{
+    "default": true,
+    "MD024": false,
+    "MD013": false,
+    "MD026": false,
+    "MD046": false,
+    "MD025": false,
+    "MD004": {"style": "asterisk"}
+}

.markdownlintrc

@@ -0,0 +1,9 @@
+{
+    "default": true,
+    "MD024": false,
+    "MD013": false,
+    "MD026": false,
+    "MD046": false,
+    "MD025": false,
+    "MD004": {"style": "asterisk"}
+}

build-system/pr-validation.yaml

@@ -34,6 +34,24 @@ jobs:
       - task: CmdLine@2
         inputs:
           script: 'cspell --config ./docs/cSpell.json "docs/**/*.md"'
+  - job: DocsMarkdownLinting
+    displayName: "Docs: Markdown Linting"
+    pool:
+      vmImage: ubuntu-20.04
+    steps:
+      - checkout: self # self represents the repo where the initial Pipelines YAML file was found
+        clean: false # whether to fetch clean each time
+        submodules: recursive # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
+      - task: NodeTool@0
+        inputs:
+          versionSpec: "12.x"
+      - task: Npm@1
+        inputs:
+          command: "custom"
+          customCommand: "install -g markdownlint-cli"
+      - task: CmdLine@2
+        inputs:
+          script: 'markdownlint "docs/**/*.md"'
   - job: WindowsBuild
     displayName: Windows Build
     pool:
@@ -140,10 +158,10 @@ jobs:
 
   - template: azure-pipeline.mntr-template.yaml
     parameters:
-      name: 'net_5_mntr_windows'
-      displayName: '.NET 5 Multi-Node Tests (Windows)'
-      vmImage: 'windows-2019'
-      scriptFileName: 'build.cmd'
+      name: "net_5_mntr_windows"
+      displayName: ".NET 5 Multi-Node Tests (Windows)"
+      vmImage: "windows-2019"
+      scriptFileName: "build.cmd"
       scriptArgs: MultiNodeTestsNet incremental
       outputDirectory: "TestResults"
       artifactName: "net_5_mntr_windows-$(Build.BuildId)"

docs/articles/actors/receive-actor-api.md

@@ -474,7 +474,7 @@ Receive<string>(s => s.Length > 2, s => Console.WriteLine("2: " + s));    //2
 Receive<string>(s => Console.WriteLine("3: " + s));                     //3
 ```
 
-Some examples: 
+Some examples:
 
 * The actor receives the message "123456". Since the length of is 6, the predicate specified for the first handler will return true, and the first handler will be invoked resulting in "1: 123456" being written to the console.
 

docs/articles/actors/testing-actor-systems.md

@@ -50,7 +50,7 @@ Keep receiving messages as long as the time is not used up and the partial funct
 
 In addition to message reception assertions there are also methods which help with messages flows:
 
-* `object ReceiveOne(TimeSpan? max = null)` 
+* `object ReceiveOne(TimeSpan? max = null)`
 
 Receive one message from the internal queue of the TestActor. This method blocks the specified duration or until a message is received. If no message was received, null is returned.
 

docs/articles/intro/what-problems-does-actor-model-solve.md

@@ -51,7 +51,7 @@ one thread will enter the method at any given time, this is a very costly strate
    unacceptable, we want to keep user-facing parts of applications (its UI) to be responsive even when a
    long background job is running. In the backend, blocking is outright wasteful.
    One might think that this can be compensated by launching new threads, but threads are also a costly abstraction.
-* Locks introduce a new menace: deadlocks.     
+* Locks introduce a new menace: deadlocks.
 
 These realities result in a no-win situation:
 

docs/articles/remoting/index.md

@@ -112,7 +112,7 @@ In the above section we mentioned that you have to bind a *transport* to an IP a
 Well, let's take a step back to define some key terms you'll need to be familiar with in order to use Akka.Remote:
 
 * **Transport** - a "transport" refers to an actual network transport, such as TCP or UDP. By default Akka.Remote uses a [DotNetty](https://github.com/Azure/DotNetty) TCP transport, but you could write your own transport and use that instead of you wish.
-* **Address** - this refers to an IP address and port combination, just like any other IP-enabled protocol. You can also use a hostname instead of an IP address, but the hostname must be resolved to an IP address first. 
+* **Address** - this refers to an IP address and port combination, just like any other IP-enabled protocol. You can also use a hostname instead of an IP address, but the hostname must be resolved to an IP address first.
 * **Endpoint** - an "endpoint" is a specific address binding for a transport. If I open a TCP transport at `localhost:8080` then I've created an *endpoint* for that transport at that address.
 * **Association** - an "association" is a connection between two endpoints, each belonging to a different `ActorSystem`. Must have a valid *outbound* endpoint and a valid *inbound* endpoint in order to create the association.
 

docs/articles/streams/custom-stream-processing.md

@@ -601,7 +601,7 @@ class FirstValue<T> : GraphStageWithMaterializedValue<FlowShape<T, T>, Task<T>>
 
 ## Using attributes to affect the behavior of a stage
 
-> [!NOTE] 
+> [!NOTE]
 > This section is a stub and will be extended in the next release.
 
 Stages can access the `Attributes` object created by the materializer. This contains all the applied (inherited) attributes applying to the stage, ordered from least specific (outermost) towards the most specific (innermost) attribute. It is the responsibility of the stage to decide how to reconcile this inheritance chain to a final effective decision.

docs/articles/streams/workingwithgraphs.md

@@ -28,7 +28,7 @@ Akka Streams currently provide these junctions (for a detailed list see [Overvie
   * ``Broadcast<T>`` – *(1 input, N outputs)* given an input element emits to each output
   * ``Balance<T>`` – *(1 input, N outputs)* given an input element emits to one of its output ports
   * ``UnzipWith<In,A,B,...>`` – *(1 input, N outputs)* takes a function of 1 input that given a value for each input emits N output elements (where N <= 20)
-  * ``UnZip<A,B>`` – *(1 input, 2 outputs)* splits a stream of ``(A,B)`` tuples into two streams, one of type ``A`` and one of type ``B``   
+  * ``UnZip<A,B>`` – *(1 input, 2 outputs)* splits a stream of ``(A,B)`` tuples into two streams, one of type ``A`` and one of type ``B``
 * **Fan-in**
   * ``Merge<In>`` – *(N inputs , 1 output)* picks randomly from inputs pushing them one by one to its output
   * ``MergePreferred<In>`` – like `Merge` but if elements are available on ``preferred`` port, it picks from it, otherwise randomly from ``others``