From ef057f77d37c13e6aaf81d3c4b990a0a30ee6bd8 Mon Sep 17 00:00:00 2001 From: Sean Killeen Date: Mon, 25 Oct 2021 15:16:29 -0400 Subject: [PATCH] Markdown linting: build steps and last fixes (#5345) * add linting config files * fix some trailing spaces * trailing spaces * add build step --- .markdownlint.json | 9 +++++++ .markdownlintrc | 9 +++++++ build-system/pr-validation.yaml | 26 ++++++++++++++++--- docs/articles/actors/receive-actor-api.md | 2 +- docs/articles/actors/testing-actor-systems.md | 2 +- .../what-problems-does-actor-model-solve.md | 2 +- docs/articles/remoting/index.md | 2 +- .../streams/custom-stream-processing.md | 2 +- docs/articles/streams/workingwithgraphs.md | 2 +- 9 files changed, 46 insertions(+), 10 deletions(-) create mode 100644 .markdownlint.json create mode 100644 .markdownlintrc diff --git a/.markdownlint.json b/.markdownlint.json new file mode 100644 index 00000000000..32b26e73233 --- /dev/null +++ b/.markdownlint.json @@ -0,0 +1,9 @@ +{ + "default": true, + "MD024": false, + "MD013": false, + "MD026": false, + "MD046": false, + "MD025": false, + "MD004": {"style": "asterisk"} +} \ No newline at end of file diff --git a/.markdownlintrc b/.markdownlintrc new file mode 100644 index 00000000000..32b26e73233 --- /dev/null +++ b/.markdownlintrc @@ -0,0 +1,9 @@ +{ + "default": true, + "MD024": false, + "MD013": false, + "MD026": false, + "MD046": false, + "MD025": false, + "MD004": {"style": "asterisk"} +} \ No newline at end of file diff --git a/build-system/pr-validation.yaml b/build-system/pr-validation.yaml index b71e3eef393..4e5405b120c 100644 --- a/build-system/pr-validation.yaml +++ b/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)" diff --git a/docs/articles/actors/receive-actor-api.md b/docs/articles/actors/receive-actor-api.md index 45931654c9b..d9445b296be 100644 --- a/docs/articles/actors/receive-actor-api.md +++ b/docs/articles/actors/receive-actor-api.md @@ -474,7 +474,7 @@ Receive(s => s.Length > 2, s => Console.WriteLine("2: " + s)); //2 Receive(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. diff --git a/docs/articles/actors/testing-actor-systems.md b/docs/articles/actors/testing-actor-systems.md index c26f4f84d9c..955865897cf 100644 --- a/docs/articles/actors/testing-actor-systems.md +++ b/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. diff --git a/docs/articles/intro/what-problems-does-actor-model-solve.md b/docs/articles/intro/what-problems-does-actor-model-solve.md index ee571311f33..0b96c0e2b35 100644 --- a/docs/articles/intro/what-problems-does-actor-model-solve.md +++ b/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: diff --git a/docs/articles/remoting/index.md b/docs/articles/remoting/index.md index 59f30ff4680..7f643466431 100644 --- a/docs/articles/remoting/index.md +++ b/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. diff --git a/docs/articles/streams/custom-stream-processing.md b/docs/articles/streams/custom-stream-processing.md index 8568c5c6d59..198cd3458fb 100644 --- a/docs/articles/streams/custom-stream-processing.md +++ b/docs/articles/streams/custom-stream-processing.md @@ -601,7 +601,7 @@ class FirstValue : GraphStageWithMaterializedValue, Task> ## 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. diff --git a/docs/articles/streams/workingwithgraphs.md b/docs/articles/streams/workingwithgraphs.md index adff3c39ec1..90528401309 100644 --- a/docs/articles/streams/workingwithgraphs.md +++ b/docs/articles/streams/workingwithgraphs.md @@ -28,7 +28,7 @@ Akka Streams currently provide these junctions (for a detailed list see [Overvie * ``Broadcast`` – *(1 input, N outputs)* given an input element emits to each output * ``Balance`` – *(1 input, N outputs)* given an input element emits to one of its output ports * ``UnzipWith`` – *(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`` – *(1 input, 2 outputs)* splits a stream of ``(A,B)`` tuples into two streams, one of type ``A`` and one of type ``B`` + * ``UnZip`` – *(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`` – *(N inputs , 1 output)* picks randomly from inputs pushing them one by one to its output * ``MergePreferred`` – like `Merge` but if elements are available on ``preferred`` port, it picks from it, otherwise randomly from ``others``