Add pre-commit CI (#167)

* Add pre-commit CI Signed-off-by: Kenji Miyake <[email protected]> * Add .prettierrc.yaml Signed-off-by: Kenji Miyake <[email protected]> * Ignore some markdownlint rules Signed-off-by: Kenji Miyake <[email protected]> * Apply format Signed-off-by: Kenji Miyake <[email protected]> * Fix typo Signed-off-by: Kenji Miyake <[email protected]> * Fix typo Signed-off-by: Kenji Miyake <[email protected]>
autowarefoundation · Jul 15, 2021 · c836a84 · c836a84
1 parent cbbb595
commit c836a84
Show file tree

Hide file tree

Showing 54 changed files with 1,226 additions and 897 deletions.
diff --git a/.clang-format b/.clang-format
@@ -22,4 +22,3 @@ ReflowComments: false
 # because it crushes include-groups unless IncludeCategories are defined properly.
 # It was introduced in https://github.com/llvm-mirror/clang/commit/62e3198c4f5490a1c60ba51d81fe2e1f0dc99135
 IncludeBlocks: Preserve
-...
diff --git a/.github/workflows/pre-commit.yaml b/.github/workflows/pre-commit.yaml
@@ -0,0 +1,23 @@
+name: pre-commit
+
+on:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  pre-commit:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 0
+
+      - name: Setup Python
+        uses: actions/setup-python@v2
+
+      - name: Run pre-commit
+        uses: pre-commit/[email protected]
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.markdownlint.yaml b/.markdownlint.yaml
@@ -0,0 +1,7 @@
+default: true
+MD013: false
+MD024:
+  siblings_only: true
+MD029: false
+MD033: false
+MD041: false
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
@@ -0,0 +1,43 @@
+# To use:
+#
+#     pre-commit run -a
+#
+# Or:
+#
+#     pre-commit install  # (runs every time you commit in git)
+#
+# To update this file:
+#
+#     pre-commit autoupdate
+#
+# See https://github.com/pre-commit/pre-commit
+
+repos:
+  # Standard hooks
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.0.1
+    hooks:
+      - id: check-json
+      - id: check-merge-conflict
+      - id: check-toml
+      - id: check-xml
+      - id: check-yaml
+      - id: detect-private-key
+      - id: double-quote-string-fixer
+      - id: end-of-file-fixer
+      - id: mixed-line-ending
+      - id: trailing-whitespace
+        args: [--markdown-linebreak-ext=md]
+
+  - repo: https://github.com/igorshubovych/markdownlint-cli
+    rev: v0.27.1
+    hooks:
+      - id: markdownlint
+        args: ["-c", ".markdownlint.yaml", "--fix"]
+
+  - repo: https://github.com/pre-commit/mirrors-prettier
+    rev: v2.3.2
+    hooks:
+      - id: prettier
+
+exclude: ".svg"
diff --git a/.prettierrc.yaml b/.prettierrc.yaml
@@ -0,0 +1,2 @@
+printWidth: 120
+tabWidth: 2
diff --git a/README.md b/README.md
@@ -4,5 +4,6 @@
 
 AutowareArchitectureProposal is a repository to explore and establish the architecture design of Autoware, an autonomous driving software managed by Autoware Foundation.
 
-# Documentation
+## Documentation
+
 See [Github Pages](https://tier4.github.io/autoware.proj/tree/main/)
diff --git a/ansible/ansible.cfg b/ansible/ansible.cfg
@@ -1,2 +1,2 @@
 [defaults]
-cow_selection = random
+cow_selection = random
diff --git a/ansible/roles/cuda/tasks/main.yml b/ansible/roles/cuda/tasks/main.yml
@@ -28,7 +28,7 @@
 - name: CUDA (install CUDA 11.1)
   become: yes
   apt:
-    name: cuda-11-1  # nvidia-driver should be greater than 455
+    name: cuda-11-1 # nvidia-driver should be greater than 455
     update_cache: yes
 
 - name: CUDA (add path >> bashrc)

diff --git a/ansible/roles/pacmod/tasks/main.yml b/ansible/roles/pacmod/tasks/main.yml
@@ -4,4 +4,3 @@
 - import_tasks: pacmod.yml
   when:
     - not kvaser_library_only
-
diff --git a/docs/Credits.md b/docs/Credits.md
@@ -1,18 +1,18 @@
 Certain AutowareArchitectureProposal packages rely on pre-trained CNN models provided by other open source repositories.
 
 - tensorrt_yolo3
-    - The pre-trained models originate from [TRTForYolov3](https://github.com/lewes6369/TensorRT-Yolov3).
-    - [Weights for the trained model](https://drive.google.com/drive/folders/18OxNcRrDrCUmoAMgngJlhEglQ1Hqk_NJ) (416 folder) are automatically downloaded during the build process.
 
+  - The pre-trained models originate from [TRTForYolov3](https://github.com/lewes6369/TensorRT-Yolov3).
+  - [Weights for the trained model](https://drive.google.com/drive/folders/18OxNcRrDrCUmoAMgngJlhEglQ1Hqk_NJ) (416 folder) are automatically downloaded during the build process.
 
 - traffic_light_fine_detector
-    - The trained model in this package is based on the [pjreddie's YOLO .weights file](https://pjreddie.com/media/files/yolov3.weights), with additional fine-tuning by Tier IV using [Darknet](https://github.com/pjreddie/darknet).
-    - After fine-tuning, the new weights for the trained model are converted into an ONNX file using [Python](https://github.com/tier4/AutowareArchitectureProposal.iv/blob/master/src/perception/traffic_light_recognition/traffic_light_fine_detector/scripts/yolov3_to_onnx.py).
 
+  - The trained model in this package is based on the [pjreddie's YOLO .weights file](https://pjreddie.com/media/files/yolov3.weights), with additional fine-tuning by Tier IV using [Darknet](https://github.com/pjreddie/darknet).
+  - After fine-tuning, the new weights for the trained model are converted into an ONNX file using [Python](https://github.com/tier4/AutowareArchitectureProposal.iv/blob/master/src/perception/traffic_light_recognition/traffic_light_fine_detector/scripts/yolov3_to_onnx.py).
 
 - lidar_apollo_instance_segmentation
-    - This package makes use of three pre-trained models provided by [Apollo Auto](https://github.com/ApolloAuto).
-    - The following files are automatically downloaded during the build process:
-        - [VLP-16](https://github.com/ApolloAuto/apollo/raw/88bfa5a1acbd20092963d6057f3a922f3939a183/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne16/deploy.caffemodel)
-        - [HDL-64](https://github.com/ApolloAuto/apollo/raw/88bfa5a1acbd20092963d6057f3a922f3939a183/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne64/deploy.caffemodel)
-        - [VLS-128](https://github.com/ApolloAuto/apollo/raw/91844c80ee4bd0cc838b4de4c625852363c258b5/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne128/deploy.caffemodel)
+  - This package makes use of three pre-trained models provided by [Apollo Auto](https://github.com/ApolloAuto).
+  - The following files are automatically downloaded during the build process:
+    - [VLP-16](https://github.com/ApolloAuto/apollo/raw/88bfa5a1acbd20092963d6057f3a922f3939a183/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne16/deploy.caffemodel)
+    - [HDL-64](https://github.com/ApolloAuto/apollo/raw/88bfa5a1acbd20092963d6057f3a922f3939a183/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne64/deploy.caffemodel)
+    - [VLS-128](https://github.com/ApolloAuto/apollo/raw/91844c80ee4bd0cc838b4de4c625852363c258b5/modules/perception/production/data/perception/lidar/models/cnnseg/velodyne128/deploy.caffemodel)
diff --git a/docs/Readme.md b/docs/Readme.md
@@ -4,9 +4,9 @@
 
 AutowareArchitectureProposal is a repository to explore and establish the architecture design of Autoware, an autonomous driving software managed by Autoware Foundation.
 
-There already exists [Autoware.Auto](https://gitlab.com/autowarefoundation/autoware.auto) repository in Autoware Foundation GitLab. The architecture investigation, however, was done as a separate repository rather than a fork to explore architecture without prejudice from the existing source code.  
+There already exists [Autoware.Auto](https://gitlab.com/autowarefoundation/autoware.auto) repository in Autoware Foundation GitLab. The architecture investigation, however, was done as a separate repository rather than a fork to explore architecture without prejudice from the existing source code.
 
-The established architecture will be presented to Autoware.Auto which will then be reviewed by the community members and be used to improve Autoware.Auto. AutowareArchitectureProposal also contains new functions that do not yet exist in Autoware.Auto to verify that the architecture is feasible for various use cases. These functions are also planned to be refactored and merged into Autoware.Auto. The details are explained in the [Future plans](#future-plans) section.  
+The established architecture will be presented to Autoware.Auto which will then be reviewed by the community members and be used to improve Autoware.Auto. AutowareArchitectureProposal also contains new functions that do not yet exist in Autoware.Auto to verify that the architecture is feasible for various use cases. These functions are also planned to be refactored and merged into Autoware.Auto. The details are explained in the [Future plans](#future-plans) section.
 
 ## Note for non-Tier IV members
 
@@ -17,12 +17,11 @@ The established architecture will be presented to Autoware.Auto which will then
 ## Target
 
 AutowareArchitectureProposal aims to realize autonomous driving in various environments.  
-Autonomous driving on public roads is an extremely challenging project, and it cannot be achieved in a short period of time. Therefore we are trying to accumulate technology by applying the current AutowareArchitectureProposal to more restricted use cases such as in-factory transportation. At the same time, demonstration experiments in public roads are also in progress.  
+Autonomous driving on public roads is an extremely challenging project, and it cannot be achieved in a short period of time. Therefore we are trying to accumulate technology by applying the current AutowareArchitectureProposal to more restricted use cases such as in-factory transportation. At the same time, demonstration experiments in public roads are also in progress.
 
 ## Future plans
 
 Again, autonomous driving is an extremely challenging project and this cannot be achieved in a short time. It cannot be achieved by only one company. People and companies all over the world need to work together to make it possible. We build the system and society through collaboration. So [Tier IV established the Autoware Foundation (AWF) in 2018](https://tier4.jp/cn/media/news/the-autoware-foundation/) to initiate, grow, and fund Autoware-related projects worldwide. [Autoware.Auto](https://www.autoware.auto/) is the current flagship AWF project and is a complete architectural redesign of [Autoware.AI](https://github.com/Autoware-AI/autoware.ai) that employs best-in-class software engineering practices.  
 As part of Tier IV's commitment to collaboration with the AWF and its members, we plan to merge the additional functionality of AutowareArchitectureProposal to Autoware.Auto. Note that since Autoware.Auto has its own scope and ODD (Operational Design Domain, prerequisite environmental conditions for an automatic driving system to operate) that needs to be achieved, not all the features in AutowareArchitectureProposal will be required.
 
 We keep using AutowareArchitectureProposal for some time, but remember that the core of our products will shift to Autoware.Auto.
-
diff --git a/docs/css/tier4_color.css b/docs/css/tier4_color.css
@@ -1,6 +1,6 @@
 :root {
-    --md-primary-fg-color:        #22a3cd;
-    --md-primary-fg-color--light: #22a3cd;
-    --md-primary-fg-color--dark:  #22a3cd;
-    --md-accent-fg-color:         #065479;
+  --md-primary-fg-color: #22a3cd;
+  --md-primary-fg-color--light: #22a3cd;
+  --md-primary-fg-color--dark: #22a3cd;
+  --md-accent-fg-color: #065479;
 }
diff --git a/docs/design/repository/Repository.md b/docs/design/repository/Repository.md
@@ -1,9 +1,10 @@
-TODO
+# TODO
+
 ## Repository Overview
 
 ## What is autoware.proj
 
 autoware.proj is a meta-repository for AutowareArchitectureProposal.  
-Since AutowareArchitectureProposal is made up of code stored in multiple, version-specific GitHub repositories, creating a new build environment would involve individually importing each repository which is both time-consuming and prone to error. To avoid both of these problems, autoware.proj was created as a meta-repository to streamline the management of all necessary repositories through the use of [vcstool](https://github.com/dirk-thomas/vcstool).  
+Since AutowareArchitectureProposal is made up of code stored in multiple, version-specific GitHub repositories, creating a new build environment would involve individually importing each repository which is both time-consuming and prone to error. To avoid both of these problems, autoware.proj was created as a meta-repository to streamline the management of all necessary repositories through the use of [vcstool](https://github.com/dirk-thomas/vcstool).
 
 autoware.proj is the top directory of the AutowareArchitectureProposal project. Therefore, this repository contains high-level information of AutowareArchitectureProposal such as [the architecture design](/docs/design/software_architecture/Overview.md).
diff --git a/docs/design/software_architecture/Control/Control.md b/docs/design/software_architecture/Control/Control.md
@@ -1,6 +1,6 @@
 # Control
 
-# Overview
+## Overview
 
 Control stack generates control signals to drive a vehicle following trajectories considering vehicle dynamics.
 This layer ensures that the vehicle follows the trajectory planned by planning.
@@ -67,7 +67,7 @@ The main outputs included in Vehicle Command are as follows.
 
 As above requirements, the control stack outputs gear shifting command and acceleration command as Vehicle command
 
-# Design
+## Design
 
 ![ControlOverview](image/ControlOverview.svg)
 
@@ -113,6 +113,6 @@ Systematic post-processing of vehicle control command, independent of trajectory
 
 - Control signal for vehicles
 
-# References
+## References
 
 TBU
diff --git a/docs/design/software_architecture/Control/TrajectoryFollower/LatLonCoupler.md b/docs/design/software_architecture/Control/TrajectoryFollower/LatLonCoupler.md
@@ -1,6 +1,6 @@
 # Latlon Coupler
 
-# Overview
+## Overview
 
 ## Role
 
@@ -33,6 +33,7 @@ Latlon Coupler module integrates lateral control command and longitudinal contro
 ### Output
 
 `autoware_control_msgs/ControlCommandStamped`:
+
 | Input                   | Data Type        | Explanation                      |
 | ----------------------- | ---------------- | -------------------------------- |
 | Velocity                | std_msgs/Float64 | from Longitudinal Control module |

diff --git a/docs/design/software_architecture/Control/TrajectoryFollower/LateralController.md b/docs/design/software_architecture/Control/TrajectoryFollower/LateralController.md
@@ -1,6 +1,6 @@
 # Lateral Controller
 
-# Overview
+## Overview
 
 For following target trajectory, control stack needs to output lateral control commands (steering angle, steering angle velocity), and longitudinal control commands (acceleration, velocity). Lateral controller module is responsible for calculation of lateral control commands.
 

diff --git a/...sign/software_architecture/Control/TrajectoryFollower/LongitudinalController.md b/...sign/software_architecture/Control/TrajectoryFollower/LongitudinalController.md
@@ -1,6 +1,6 @@
 # Longitudinal Controller
 
-# Overview
+## Overview
 
 For following target trajectory, control stack needs to output lateral control commands (steering angle, steering angle velocity), and longitudinal control commands (acceleration, velocity). Longitudinal controller module is responsible for calculation of longitudinal control commands.
 

diff --git a/docs/design/software_architecture/Control/VehicleCmdGate/VehicleCmdGate.md b/docs/design/software_architecture/Control/VehicleCmdGate/VehicleCmdGate.md
@@ -1,6 +1,6 @@
 # Vehicle Cmd Gate
 
-# Overview
+## Overview
 
 Vehicle Cmd Gate module is responsible for Systematic post-processing.
 

diff --git a/docs/design/software_architecture/ForDevelopers.md b/docs/design/software_architecture/ForDevelopers.md
@@ -4,19 +4,21 @@ In order to test Autoware in a real vehicle, it is necessary to setup Autoware f
 
 ## 1. Sensor TF
 
-* The sensor TF describes the positional relationship of each sensor to the vehicle's base link (defined as the center of the vehicle's rear axle) and has to be created for each configuration of sensors.
-* Please setup following the [TF design document](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/TF.md).
+- The sensor TF describes the positional relationship of each sensor to the vehicle's base link (defined as the center of the vehicle's rear axle) and has to be created for each configuration of sensors.
+- Please setup following the [TF design document](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/TF.md).
 
 ## 2. Vehicle interface
-* The [vehicle interface](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md#vehicle-interface) is the Autoware module that communicates with the vehicle's DBW (drive-by-wire) system, and must be created for each specific combination of vehicle and DBW.
-* Please create an appropriate vehicle interface following the ["How to design a new vehicle interface"](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md#how-to-design-a-new-vehicle-interface) section of the [Vehicle stack design document](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md).
-* [Sample vehicle interface file](https://github.com/tier4/lexus_description.iv.universe/blob/master/launch/vehicle_interface.launch) (for the Lexus RX 450H vehicle using [AutonomouStuff's PacMod system](https://autonomoustuff.com/products/pacmod))
+
+- The [vehicle interface](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md#vehicle-interface) is the Autoware module that communicates with the vehicle's DBW (drive-by-wire) system, and must be created for each specific combination of vehicle and DBW.
+- Please create an appropriate vehicle interface following the ["How to design a new vehicle interface"](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md#how-to-design-a-new-vehicle-interface) section of the [Vehicle stack design document](https://github.com/tier4/AutowareArchitectureProposal.proj/blob/master/design/Vehicle/Vehicle.md).
+- [Sample vehicle interface file](https://github.com/tier4/lexus_description.iv.universe/blob/master/launch/vehicle_interface.launch) (for the Lexus RX 450H vehicle using [AutonomouStuff's PacMod system](https://autonomoustuff.com/products/pacmod))
 
 ## 3. Vehicle info
 
-* The `vehicle_info` YAML configuration file contains global parameters for the vehicle's physical configuration (e.g. wheel radius) that are read by Autoware in [rosparam format](http://wiki.ros.org/rosparam) and published to the ROS Parameter Server.
-* The required parameters are as follows:
-```
+- The `vehicle_info` YAML configuration file contains global parameters for the vehicle's physical configuration (e.g. wheel radius) that are read by Autoware in [rosparam format](http://wiki.ros.org/rosparam) and published to the ROS Parameter Server.
+- The required parameters are as follows:
+
+```txt
 /vehicle_info/wheel_radius    # wheel radius
 /vehicle_info/wheel_width     # wheel width
 /vehicle_info/wheel_base      # between front wheel center and rear wheel center
@@ -25,9 +27,10 @@ In order to test Autoware in a real vehicle, it is necessary to setup Autoware f
 /vehicle_info/rear_overhang   # between rear wheel center and vehicle rear
 /vehicle_info/vehicle_height  # from the ground point to the highest point
 ```
-* [Sample vehicle info file](https://github.com/tier4/lexus_description.iv.universe/blob/master/config/vehicle_info.yaml) (for the Lexus RX 450H)
+
+- [Sample vehicle info file](https://github.com/tier4/lexus_description.iv.universe/blob/master/config/vehicle_info.yaml) (for the Lexus RX 450H)
 
 ## 4. Sensor launch file
 
-* The `sensor.launch` file defines which sensor driver nodes are launched when running Autoware, and is dependent on the specific sensors (type, OEM and model) that are to be used.
-* [Sample sensor.launch file](https://github.com/tier4/autoware_launcher.iv.universe/blob/master/sensing_launch/launch/sensing.launch)
+- The `sensor.launch` file defines which sensor driver nodes are launched when running Autoware, and is dependent on the specific sensors (type, OEM and model) that are to be used.
+- [Sample sensor.launch file](https://github.com/tier4/autoware_launcher.iv.universe/blob/master/sensing_launch/launch/sensing.launch)