Fix MD025 warnings
The following warnings are generated by using markdownlint analysis:
```
docs/testing.md:140 MD025/single-title/single-h1 Multiple top-level headings in the same document [Context: "# Writing Tests"]
docs/testing.md:427 MD025/single-title/single-h1 Multiple top-level headings in the same document [Context: "# Reviewing Tests"]
docs/testing.md:470 MD025/single-title/single-h1 Multiple top-level headings in the same document [Context: "# Credits"]
docs/configuration.md:25 MD025/single-title/single-h1 Multiple top-level headings in the same document [Context: "# IPMI D-Bus Sensor Filtering"]
```
Refer to markdown-lint [1] to fix MD025
[1]: https://github.com/updownpress/markdown-lint/blob/master/rules/025-single-h1.md
Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I0e59219d9327db7a2589ada84615f9dc345373d5
diff --git a/docs/configuration.md b/docs/configuration.md
index 061e3d5..67e588f 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -1,4 +1,6 @@
-# Device ID Configuration
+# Configuration
+
+## Device ID Configuration
There is a default dev_id.json file provided by
meta-phosphor/common/recipes-phosphor/ipmi/phosphor-ipmi-host.bb
@@ -22,7 +24,7 @@
runtime, simply restart the service to see the new data fetched by a call to
get_device_id.
-# IPMI D-Bus Sensor Filtering
+## IPMI D-Bus Sensor Filtering
Phosphor-ipmi-host provides a compile time option to control how IPMI sensors
are populated. The default model is for the sensors to be culled from a set of
diff --git a/docs/testing.md b/docs/testing.md
index 2fa3602..9ee1dcb 100644
--- a/docs/testing.md
+++ b/docs/testing.md
@@ -31,7 +31,7 @@
git clone https://github.com/openbmc/openbmc-build-scripts.git
```
-### Add `phosphor-host-ipmid`
+## Add `phosphor-host-ipmid`
We also need to put a copy of the project you want to test against here. But
you've probably got a copy checked out already, so we're going to make a _git
@@ -116,7 +116,7 @@
in parallel while the tests run, and since the CI scripts are unhappy when you
have untracked changes - which you're likely to have during active development.
-## Building and Running
+### Building and Running
The OpenBMC CI scripts take care of the build for you, and run the test suite.
Build and run like so:
@@ -129,7 +129,7 @@
The first run will take a long time! But afterwards it shouldn't be so bad, as
many parts of the Docker container are already downloaded and configured.
-## Reading Output
+### Reading Output
Your results will appear in
`openbmc-ci-tests/phosphor-host-ipmid/test/test-suite.log`, as well as being
@@ -137,12 +137,12 @@
test file, for example `sample_unittest.log`. All these `*.log` files are
human-readable and can be examined to determine why something failed
-# Writing Tests
+### Writing Tests
Now that you've got an easy working environment for running tests, let's write
some new ones.
-## Setting Up Your Environment
+### Setting Up Your Environment
In `/my/dir/for/phosphor-host-ipmid`, create a new branch based on `master` (or
your current patchset). For this tutorial, let's call it `sensorhandler-tests`.
@@ -154,7 +154,7 @@
This creates a new branch `sensorhandler-tests` which is based on `master`, then
checks out that branch for you to start hacking.
-## Write Some Tests
+### Write Some Tests
For this tutorial, we'll be adding some basic unit testing of the struct
accessors for `get_sdr::GetSdrReq`, just because they're fairly simple. The text
@@ -345,7 +345,7 @@
check_PROGRAMS += %reldir%/sensorhandler_unittest
```
-## Run the New Tests
+### Run the New Tests
Commit your test changes. Then, you'll want to checkout the
`sensorhandler-tests` branch in your CI worktree, which will involve releasing
@@ -373,7 +373,7 @@
(If you will need to apply the proposed changes to multiple commits, you can do
this with interactive rebase, which won't be described here.)
-## Best Practices
+### Best Practices
While a good unit test can ensure your code's stability, a flaky or
poorly-written unit test can make life harder for contributors down the road.
@@ -418,13 +418,13 @@
master -> fix Foo.Abc() -> fix Foo.Def() -> Fix Foo.Ghi() -> test Foo class
-## Sending for Review
+### Sending for Review
You can send your test update and any associated bugfixes for review to Gerrit
as you would send any other change. For the `Tested:` field in the commit
message, you can state that you ran the new unit tests written.
-# Reviewing Tests
+### Reviewing Tests
Tests are written primarily to be read. So when you review a test, you're the
first customer of that test!
@@ -467,7 +467,7 @@
- The committer doesn't have "Ok-To-Test" permission, and you don't have
permission to grant it to them
-# Credits
+## Credits
Thanks very much to Patrick Venture for his prior work putting together
documentation on this topic internal to Google.