format: reformat with latest openbmc-build-scripts

Reformat the repository using the latest from openbmc-build-scripts.
Add the `static/redfish` directory to be ignored by prettier since
these files come from elsewhere and having the ability to do a direct
diff is handy.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I74464d6f97047b4888a591e0d8a4f5ca970ac69e

1 files changed, 47 insertions, 29 deletions

diff --git a/TESTING.md b/TESTING.md
index 5a489f02ff..f335392dde 100644
--- a/TESTING.md
+++ b/TESTING.md
@@ -6,50 +6,61 @@ should add types of testing they performed and their results as "Tested" footers
 in commit messages.
 
 ## General Methodology
-There are a variety of ways to develop and test bmcweb software changes.
-Here are the steps for using the SDK and QEMU.
-
-- Follow all [development environment setup](https://github.com/openbmc/docs/blob/master/development/dev-environment.md)
-directions in the development environment setup document. This will get
-QEMU started up and you in the SDK environment.
-- Follow all of the [gerrit setup](https://github.com/openbmc/docs/blob/master/development/gerrit-setup.md)
-directions in the gerrit setup document.
+
+There are a variety of ways to develop and test bmcweb software changes. Here
+are the steps for using the SDK and QEMU.
+
+- Follow all
+  [development environment setup](https://github.com/openbmc/docs/blob/master/development/dev-environment.md)
+  directions in the development environment setup document. This will get QEMU
+  started up and you in the SDK environment.
+- Follow all of the
+  [gerrit setup](https://github.com/openbmc/docs/blob/master/development/gerrit-setup.md)
+  directions in the gerrit setup document.
 - Clone bmcweb from gerrit
+
   ```
   git clone ssh://openbmc.gerrit/openbmc/bmcweb/
   ```
 
-- Follow directions in [README.md](https://github.com/openbmc/bmcweb#configuration) to compile
+- Follow directions in
+  [README.md](https://github.com/openbmc/bmcweb#configuration) to compile
 
 - Reduce binary size by stripping it when ready for testing
+
   ```
   arm-openbmc-linux-gnueabi-strip bmcweb
   ```
+
   **Note:** Stripping is not required and having the debug symbols could be
-  useful depending on your testing. Leaving them will drastically increase
-  your transfer time to the BMC.
+  useful depending on your testing. Leaving them will drastically increase your
+  transfer time to the BMC.
 
 - Copy your bmcweb you want to test to /tmp/ in QEMU
+
   ```
   scp -P 2222 bmcweb root@127.0.0.1:/tmp/
   ```
-  **Special Notes:**
-  The address and port shown here (127.0.0.1 and 2222) reaches the QEMU session
-  you set up in your development environment as described above.
+
+  **Special Notes:** The address and port shown here (127.0.0.1 and 2222)
+  reaches the QEMU session you set up in your development environment as
+  described above.
 
 - Stop bmcweb service within your QEMU session
+
   ```
   systemctl stop bmcweb
   ```
+
   **Note:** bmcweb supports being started directly in parallel with the bmcweb
   running as a service. The standalone bmcweb will be available on port 18080.
-  An advantage of this is you can compare between the two easily for testing.
-  In QEMU you would need to open up port 18080 when starting QEMU. Your curl
+  An advantage of this is you can compare between the two easily for testing. In
+  QEMU you would need to open up port 18080 when starting QEMU. Your curl
   commands would need to use 18080 to communicate.
 
-- If running within a system that has read-only /usr/ filesystem, issue
-the following commands one time per QEMU boot to make the filesystem
-writeable
+- If running within a system that has read-only /usr/ filesystem, issue the
+  following commands one time per QEMU boot to make the filesystem writeable
+
   ```
   mkdir -p /var/persist/usr
   mkdir -p /var/persist/work/usr
@@ -57,32 +68,37 @@ writeable
   ```
 
 - Remove the existing bmcweb from the filesystem in QEMU
+
   ```
   rm /usr/bin/bmcweb
   ```
 
 - Link to your new bmcweb in /tmp/
+
   ```
   ln -sf /tmp/bmcweb /usr/bin/bmcweb
   ```
 
-- Test your changes. bmcweb will be started automatically upon your
-first REST or Redfish command
+- Test your changes. bmcweb will be started automatically upon your first REST
+  or Redfish command
+
   ```
   curl -c cjar -b cjar -k -X POST https://127.0.0.1:2443/login -d "{\"data\": [ \"root\", \"0penBmc\" ] }"
   curl -c cjar -b cjar -k -X GET https://127.0.0.1:2443/xyz/openbmc_project/state/bmc0
   ```
 
-- Stop the bmcweb service and scp new file over to /tmp/ each time you
-want to retest a change.
+- Stop the bmcweb service and scp new file over to /tmp/ each time you want to
+  retest a change.
 
   See the [REST](https://github.com/openbmc/docs/blob/master/REST-cheatsheet.md)
-  and [Redfish](https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md) cheatsheets for valid commands.
-
+  and
+  [Redfish](https://github.com/openbmc/docs/blob/master/REDFISH-cheatsheet.md)
+  cheatsheets for valid commands.
 
 ## Types of Changes to Run
-A committer should run tests that exercise all paths changed in the patchset.
-If making changes to the http core, that are expected to effect all types of
+
+A committer should run tests that exercise all paths changed in the patchset. If
+making changes to the http core, that are expected to effect all types of
 routes, testing one route of each class (websocket, HTTP get, HTTP post) is
 required.
 
@@ -90,7 +106,8 @@ required.
 
 ### Basic Redfish Robot Test on QEMU
 
-Run the [upstream Robot QEMU test](https://github.com/openbmc/openbmc-build-scripts/blob/master/run-qemu-robot-test.sh).
+Run the
+[upstream Robot QEMU test](https://github.com/openbmc/openbmc-build-scripts/blob/master/run-qemu-robot-test.sh).
 This test is performed automatically when bumping SRCREV. Ensuring this test
 passing makes your CL less likely to be rolled back while bumping SRCREV of
 bmcweb.
@@ -106,7 +123,8 @@ $ python scripts/websocket_test.py  --host 1.2.3.4:443 --ssl
 
 ### Redfish Validator
 
-Commiters are required to run the [Redfish Validator](https://github.com/DMTF/Redfish-Service-Validator.git)
+Commiters are required to run the
+[Redfish Validator](https://github.com/DMTF/Redfish-Service-Validator.git)
 anytime they make a change to the GET behavior of the redfish tree. The test
 must run on real hardware since the resource tree will be more complete.