Linting

Author: ruffsl

ros/content.md

@@ -134,17 +134,17 @@ CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"]
 The example above consists of three sequential stages. The `cacher` stage first updates the apt lists and ROS index, uses [`vcstool`](https://github.com/dirk-thomas/vcstool) to clone a demo repo into the workspace source directory, and derives build and runtime dependency sets using [`rosdep`](https://docs.ros.org/en/rolling/Tutorials/Intermediate/Rosdep.html). The `builder` stage installs the derived build dependencies, sources the ROS install underlay, and compiles the source in release mode using [`colcon`](https://docs.ros.org/en/rolling/Tutorials/Beginner-Client-Libraries/Colcon-Tutorial.html). Finally, the `runner` stage installs only runtime dependencies, copies the compiled workspace artifacts, and sets up the environment to launch the demo. Note the example consists of several subtle optimizations:
 
 -	Multi-Stage Build
-    -	Dependency derivation, compilation, and runtime setup are partitioned
-    -	Maximizes cache retention despite package source or build/runtime changes
-    -	Greater concurrency, e.g., colcon build while runtime apt installs
+	-	Dependency derivation, compilation, and runtime setup are partitioned
+	-	Maximizes cache retention despite package source or build/runtime changes
+	-	Greater concurrency, e.g., colcon build while runtime apt installs
 -	Persistent Cache Propagation
-    -	Use of [`--mount`](https://docs.docker.com/engine/reference/builder/#run---mount) to cache temp data without bloating layers
-    -	Maintain temporally consistent apt lists between parallel stages
-    -	Avoid needless network I/O between stages or across Docker rebuilds
+	-	Use of [`--mount`](https://docs.docker.com/engine/reference/builder/#run---mount) to cache temp data without bloating layers
+	-	Maintain temporally consistent apt lists between parallel stages
+	-	Avoid needless network I/O between stages or across Docker rebuilds
 -	Minimal Image Size
-    -	Final stage builds from `ros-core` for smallest runtime image
-    -	Builds and installs only a select few packages in the workspace
-    -	Only workspace install artifacts are copied into final layers
+	-	Final stage builds from `ros-core` for smallest runtime image
+	-	Builds and installs only a select few packages in the workspace
+	-	Only workspace install artifacts are copied into final layers
 
 For comparison, the resulting `runner` image is similar in size to the earlier `installer` example. This allows you to develop and distribute custom ROS packages without significantly increasing image size compared to pre-built Debian installations:
 
@@ -160,7 +160,7 @@ rolling-ros-core   489MB
 rolling            876MB
 ```
 
-For more advanced examples, such as daisy-chaining multiple overlay workspaces to improve caching of Docker image build layers, using tools such as ccache to accelerate compilation with colcon, or using BuildKit to save build time and bandwidth even when dependencies change, the project `Dockerfile`s in the [Navigation2](https://github.com/ros-planning/navigation2) repo are excellent resources.
+For more advance examples such as daisy chaining multiple overlay workspaces to improve caching of docker image build layers, using tools such as ccache to accelerate compilation with colcon, or using buildkit to save build time and bandwidth even when dependencies change, the project `Dockerfile`s in the [Navigation2](https://github.com/ros-planning/navigation2) repo are excellent resources.
 
 ## Deployment use cases