docs: Apply bullet style changes from Prettier.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

docs/testing/continuous-integration.md

@@ -13,10 +13,10 @@ many possible future bugs as possible, while minimizing both latency
 and false positives, both of which can waste a lot of developer time.
 There are a few implications of this overall goal:
 
-* If a test is failing nondeterministically in CI, we consider that to
+- If a test is failing nondeterministically in CI, we consider that to
 be an urgent problem.
-* If the tests become a lot slower, that is also an urgent problem.
-* Everything we do in CI should also have a way to run it quickly
+- If the tests become a lot slower, that is also an urgent problem.
+- Everything we do in CI should also have a way to run it quickly
 (under 1 minute, preferably under 3 seconds), in order to iterate fast
 in development. Except when working on the CI configuration itself, a
 developer should never have to repeatedly wait 10 minutes for a full CI
@@ -26,16 +26,16 @@ run to iteratively debug something.
 
 ### Useful debugging tips and tools
 
-* GitHub Actions stores timestamps for every line in the logs. They
+- GitHub Actions stores timestamps for every line in the logs. They
 are hidden by default; you can see them by toggling the
 `Show timestamps` option in the menu on any job's log page.  (You can
 get this sort of timestamp in a development environment by piping
 output to `ts`).
 
-* GitHub Actions runs on every branch you push on your Zulip fork.
+- GitHub Actions runs on every branch you push on your Zulip fork.
 This is helpful when debugging something complicated.
 
-* You can also ssh into a container to debug failures.  SSHing into
+- You can also ssh into a container to debug failures.  SSHing into
 the containers can be helpful, especially in rare cases where the
 tests are passing in your computer but failing in the CI. There are
 various
@@ -106,8 +106,8 @@ between jobs the various caches that live under `/srv/` in a Zulip
 development or production environment.  In particular, we cache the
 following:
 
-* Python virtualenvs
-* node_modules directories
+- Python virtualenvs
+- node_modules directories
 
 This has a huge impact on the performance of running tests in GitHub Actions
 CI; without these caches, the average test time would be several times