Feature/303

.github/workflows/format_lint.yml

@@ -0,0 +1,51 @@
+defaults:
+  run:
+    shell: bash
+
+on:
+  push:
+    branches:
+      - master
+      - develop
+    paths:
+      - '**/*.md'
+      - '**/*.py'
+
+  pull_request:
+    branches:
+      - master
+      - develop
+    paths:
+      - '**/*.md'
+      - '**/*.py'
+
+jobs:
+  lint-python:
+    runs-on: ubuntu-18.04
+    name: Python code format check"
+    steps:
+      - uses: actions/checkout@v2
+      - name: Set up Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: 3.7
+      - name: Install necessary tools
+        run: pip install black
+      - name: Perform format check
+        working-directory: ${{ github.workspace }}
+        run: black -l 79 --diff --check .
+
+  lint-markdown:
+    runs-on: ubuntu-18.04
+    name: Markdown documents lint
+    steps:
+      - uses: actions/checkout@v2
+      - name: Set up Node
+        uses: actions/setup-node@v2-beta
+        with:
+          node-version: '14'
+      - name: Install necessary tools
+        run: npm install [email protected]
+      - name: Perform linting
+        working-directory: ${{ github.workspace }}
+        run: npx markdownlint --ignore node_modules .

.markdownlint.json

@@ -0,0 +1,23 @@
+{
+    "default": true,
+    "MD004": {
+        "style": "dash"
+    },
+    "MD007": {
+        "indent": 4
+    },
+    "MD013": {
+        "code_blocks": false,
+        "tables": false
+    },
+    "MD026": {
+        "punctuation": ".,;!?"
+    },
+    "MD029": false,
+    "MD030": {
+        "ul_single": 1,
+        "ol_single": 2,
+        "ul_multi": 3,
+        "ol_multi": 2
+    }
+}

.travis.yml

@@ -1,3 +1,4 @@
+os: linux
 dist: xenial
 language: python
 python: "3.7"
@@ -11,10 +12,20 @@ addons:
     update: true
 before_install:
   - git config --global clangFormat.binary clang-format-9
-  - gem install mdl -v 0.9.0
-  - pip install Sultan scan-build black
+  - pip install Sultan scan-build
 install:
-  - 'if [ -n "$RTI_MIN_PACKAGE_URL" ]; then resources/travis/linux_install.py; fi'
+  - |
+    if [ -n "$RTI_MIN_PACKAGE_URL" ]; then
+      resources/travis/linux_install.py
+    fi
 script:
-  - 'if [ -n "$RTI_MIN_PACKAGE_URL" ]; then resources/travis/linux_static_analysis.py; fi'
-  - 'if [ -n "$TRAVIS_COMMIT_RANGE" ]; then resources/travis/linux_format.py --commit-range $TRAVIS_COMMIT_RANGE ; else resources/travis/linux_format.py --commit $TRAVIS_COMMIT; fi'
+  - |
+    if [ -n "$TRAVIS_COMMIT_RANGE" ]; then
+      resources/travis/linux_format.py -md -py -r $TRAVIS_COMMIT_RANGE
+    else
+      resources/travis/linux_format.py -md -py -c $TRAVIS_COMMIT
+    fi
+  - |
+    if [ -n "$RTI_MIN_PACKAGE_URL" ]; then
+      resources/travis/linux_static_analysis.py
+    fi

examples/connext_dds/builtin_qos_profiles/README.md

@@ -5,7 +5,7 @@
 *RTI Connext DDS* provides *Quality of Service* (QoS) that controls the behavior
 of the different DDS entities, and allows you to configure the *middleware* to
 enable features such as monitoring. To make this process easier, RTI includes a
-set of built-in QoS profiles that provide useful *functionality, such as
+set of built-in QoS profiles that provide useful functionality, such as
 enabling monitoring or configuring *DataWriters* and *DataReaders* to be
 strictly reliable.
 

examples/connext_dds/builtin_topics/README.md

@@ -5,7 +5,7 @@
 *Built-in Topics* are a special kind of topics that are used by *RTI Connext
 *DDS* applications to discover each other. These *Topics* are handled
 automatically by the middleware, but in certain scenarios it is useful to
-*access to them. For instance, these *Topics* allow us to access some relevant
+access to them. For instance, these *Topics* allow us to access some relevant
 information about Connext entities, such as:
 
 - The publications and subscriptions available.

examples/connext_dds/coherent_presentation/README.md

@@ -28,8 +28,9 @@ allows us to do this. If there are additional dependencies *across* instances,
 topic level scope makes these changes atomic to the reader.
 
 This shows how coherent access can be used to ensure written samples are viewed
-atomically; that is, all samples sent between begin_ and end_coherent changes
-will be available before the reader is notified that there are samples to read.
+atomically; that is, all samples sent between begin_coherent and end_coherent
+changes will be available before the reader is notified that there are samples
+to read.
 
 In this example, the subscriber receives updates for six state fields, a-f.
 Because we request coherent access at the topic level, on_data_available is not

examples/connext_dds/ordered_presentation/README.md

@@ -60,5 +60,5 @@ Note that using instance access_scope does not guarantee that samples will be
 read or taken from the queue in a particular manner. Subscriber 0 returns all of
 Instance 0's samples, then all of Instance 1's samples. However, it would also
 be valid to return samples in the same order as Subscriber 1. To guarantee that
-samples from the same instance are return together, use the take/read_*instance
+samples from the same instance are return together, use the take/read_\*instance
 calls. See the on-line API for *FooDataReader* for more information.