Merge pull request #22 from tier4/sync-upstream

chore: sync upstream

.pre-commit-config.yaml

@@ -4,7 +4,7 @@ ci:
 
 repos:
   - repo: https://github.com/pre-commit/pre-commit-hooks
-    rev: v4.2.0
+    rev: v4.3.0
     hooks:
       - id: check-json
       - id: check-merge-conflict
@@ -25,7 +25,7 @@ repos:
         args: [-c, .markdownlint.yaml, --fix]
 
   - repo: https://github.com/pre-commit/mirrors-prettier
-    rev: v2.6.2
+    rev: v2.7.1
     hooks:
       - id: prettier
 
@@ -41,7 +41,7 @@ repos:
       - id: shellcheck
 
   - repo: https://github.com/scop/pre-commit-shfmt
-    rev: v3.5.0-1
+    rev: v3.5.1-1
     hooks:
       - id: shfmt
         args: [-w, -s, -i=4]

docs/contributing/coding-guidelines/.pages

@@ -1,4 +1,4 @@
 nav:
   - index.md
-  - Language-specific coding guidelines: languages
-  - ROS nodes coding guidelines: ros-nodes
+  - Language-specific guidelines: languages
+  - ROS nodes guidelines: ros-nodes

docs/contributing/coding-guidelines/index.md

@@ -5,3 +5,15 @@
     Under Construction
 
 ## Common guidelines
+
+Refer to the following links for now:
+
+- <https://docs.ros.org/en/humble/Contributing/Developer-Guide.html>
+
+Also, keep in mind the following concepts.
+
+- Keep things consistent.
+- Automate where possible, using simple checks for formatting, syntax, etc.
+- When it comes to code reviews, don't spend too much time on trivial disagreements. For details see:
+  - <https://en.wikipedia.org/wiki/Law_of_triviality>
+  - <https://steemit.com/programming/@emrebeyler/code-reviews-and-parkinson-s-law-of-triviality>

docs/contributing/coding-guidelines/languages/.pages

@@ -1,11 +1,9 @@
 nav:
-  - index.md
   - cpp.md
   - python.md
   - shell-scripts.md
   - markdown.md
   - cmake.md
   - package-xml.md
-  - ros2-interfaces.md
   - docker.md
   - github-actions.md

docs/contributing/coding-guidelines/languages/cmake.md

@@ -3,3 +3,12 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.ros.org/en/humble/Contributing/Code-Style-Language-Versions.html#cmake>
+
+## Use the autoware_package macro
+
+To reduce duplications in CMakeLists.txt, there is the `autoware_package()` macro.
+See the [README](https://github.com/autowarefoundation/autoware_common/tree/main/autoware_cmake) and use it in your package.

docs/contributing/coding-guidelines/languages/cpp.md

@@ -3,3 +3,9 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.ros.org/en/humble/Contributing/Code-Style-Language-Versions.html#id1>
+- <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>
+- <https://www.autosar.org/fileadmin/user_upload/standards/adaptive/21-11/AUTOSAR_RS_CPP14Guidelines.pdf>

docs/contributing/coding-guidelines/languages/docker.md

@@ -3,3 +3,7 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://github.com/hadolint/hadolint>

docs/contributing/coding-guidelines/languages/github-actions.md

@@ -3,3 +3,7 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.github.com/en/actions/guides>

docs/contributing/coding-guidelines/languages/markdown.md

@@ -3,3 +3,8 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.ros.org/en/foxy/Contributing/Code-Style-Language-Versions.html#markdown-restructured-text-docblocks>
+- <https://github.com/DavidAnson/markdownlint>

docs/contributing/coding-guidelines/languages/package-xml.md

@@ -3,3 +3,8 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://ros.org/reps/rep-0149.html>
+- <https://github.com/tier4/pre-commit-hooks-ros#prettier-package-xml>

docs/contributing/coding-guidelines/languages/python.md

@@ -3,3 +3,9 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.ros.org/en/foxy/Contributing/Code-Style-Language-Versions.html#python>
+- <https://github.com/psf/black>
+- <https://github.com/PyCQA/isort>

docs/contributing/coding-guidelines/languages/shell-scripts.md

@@ -3,3 +3,9 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://google.github.io/styleguide/shellguide.html>
+- <https://github.com/koalaman/shellcheck>
+- <https://github.com/mvdan/sh>

docs/contributing/coding-guidelines/ros-nodes/.pages

@@ -1,5 +1,4 @@
 nav:
-  - index.md
   - class-design.md
   - console-logging.md
   - coordinate-system.md

docs/contributing/coding-guidelines/ros-nodes/message-guidelines.md

@@ -114,7 +114,7 @@ uint8 type
 
 ## Comments
 
-On top of the message, briefly explain what the message contains and/or what it is used for. See [sensor_msgs/msg/Imu.msg](https://github.com/ros2/common_interfaces/blob/master/sensor_msgs/msg/Imu.msg#L1-L13) for an example.
+On top of the message, briefly explain what the message contains and/or what it is used for. For an example, see [sensor_msgs/msg/Imu.msg](https://github.com/ros2/common_interfaces/blob/master/sensor_msgs/msg/Imu.msg#L1-L13).
 
 !!! tip ""
 

docs/contributing/discussion-guidelines/index.md

@@ -3,3 +3,8 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://docs.github.com/en/discussions/guides/best-practices-for-community-conversations-on-github>
+- <https://opensource.guide/how-to-contribute/#communicating-effectively>

docs/contributing/documentation-guidelines/index.md

@@ -3,3 +3,7 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://developers.google.com/style>

docs/contributing/index.md

@@ -19,7 +19,7 @@ Like Autoware itself, these guidelines are being actively developed and suggesti
 
 ## Code of Conduct
 
-To ensure the Autoware community stays open and inclusive, please follow our [code of conduct](https://github.com/autowarefoundation/autoware/blob/main/CODE_OF_CONDUCT.md).
+To ensure the Autoware community stays open and inclusive, please follow the [code of conduct](https://github.com/autowarefoundation/autoware/blob/main/CODE_OF_CONDUCT.md).
 
 If you believe that someone in the community has violated the code of conduct, please make a report by emailing conduct@autoware.org.
 
@@ -90,4 +90,4 @@ Examples of large changes include:
 - Adding a new feature to Autoware
 - Adding a new documentation page or section
 
-For more information on how to submit a good pull request, have a read of our [pull request guidelines](pull-request-guidelines/index.md) and don't forget to review the required [license notations](license.md)!
+For more information on how to submit a good pull request, have a read of the [pull request guidelines](pull-request-guidelines/index.md) and don't forget to review the required [license notations](license.md)!

docs/contributing/pull-request-guidelines/commit-guidelines.md

@@ -1,7 +1,5 @@
 # Commit guidelines
 
-This page explains our guidelines related to committing.
-
 ## Branch rules
 
 ### Start branch names with the corresponding issue numbers (advisory, non-automated)

docs/contributing/pull-request-guidelines/index.md

@@ -3,20 +3,20 @@
 ## General pull request workflow
 
 Autoware uses the fork-and-pull model.
-Refer to [GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests) for the detailed explanation of the model.
+For the detailed explanation of the model, refer to [GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests).
 
-The following is a general example of our pull request workflow.
+The following is a general example of the pull request workflow.
 
 1. Create a fork. (for the first time only)
 2. Create an issue.
    - Discuss the approach to the issue with maintainers.
 3. Write code in the agreed approach.
    - Write the tests and documentation if necessary.
-   - Follow our guidelines when you write code, tests, and documentation.
+   - Follow the guidelines when you write code, tests, and documentation.
      - [Coding guidelines](../coding-guidelines/index.md)
      - [Testing guidelines](../testing-guidelines/index.md)
      - [Documentation guidelines](../documentation-guidelines/index.md)
-   - Follow our [Commit guidelines](commit-guidelines.md) when commit your change.
+   - Follow the [Commit guidelines](commit-guidelines.md) when commit your change.
 4. Test the code.
    - In the later review process, you will need to write what tests you have done.
 5. Create a pull request.
@@ -25,7 +25,7 @@ The following is a general example of our pull request workflow.
      - If you have no rights to assign reviewers, just mention them instead.
      - If you are not sure who to set reviewers, contact to the people written as the `maintainer` tag in `package.xml`.
 6. Wait for the pull request to be reviewed.
-   - The reviewers will review your code following our [review guidelines](review-guidelines.md).
+   - The reviewers will review your code following the [review guidelines](review-guidelines.md).
      - Take a look at the guidelines as well because it is good to understand the thoughts of the reviewer's side.
    - If [CI checks](#ci-checks) have failed, fix the errors.
 7. Address the review comments pointed out by the reviewers.
@@ -63,7 +63,7 @@ The Developer Certificate of Origin (DCO) is a lightweight way for contributors
 This workflow checks whether the pull request fulfills `DCO`.  
 You need to confirm the [required items](https://developercertificate.org/) and commit with `git commit -s`.
 
-Refer to the [GitHub App page](https://github.com/apps/dco) for more information.
+For more information, refer to the [GitHub App page](https://github.com/apps/dco).
 
 ### semantic-pull-request
 
@@ -75,9 +75,9 @@ Note that if there is only one commit in the pull request, you need to make the
 This is due to GitHub's non-intuitive behavior when there is only one commit.
 GitHub uses the commit title for the squashed commit message, instead of the pull request title.
 
-Refer to [amannn/action-semantic-pull-request](https://github.com/amannn/action-semantic-pull-request) for more detailed behaviors of this workflow.
+For more detailed behaviors of this workflow, refer to [amannn/action-semantic-pull-request](https://github.com/amannn/action-semantic-pull-request).
 
-See our [commit guidelines](commit-guidelines.md) for the detailed rules.
+For the detailed rules, see the [commit guidelines](commit-guidelines.md).
 
 ### pre-commit
 
@@ -125,7 +125,7 @@ This workflow is the `ARM64` version of `build-and-test-differential`.
 You need to add the `ARM64` label to run this workflow.
 
 For reference information, since ARM machines are not supported by GitHub-hosted runners, we use self-hosted runners prepared by the AWF.  
-Refer to [GitHub Docs](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners) for the details about self-hosted runners.
+For the details about self-hosted runners, refer to [GitHub Docs](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners).
 
 ### deploy-docs
 

docs/contributing/pull-request-guidelines/review-guidelines.md

@@ -3,3 +3,10 @@
 !!! warning
 
     Under Construction
+
+Refer to the following links for now:
+
+- <https://google.github.io/eng-practices/review/>
+- <https://docs.gitlab.com/ee/development/code_review.html>
+- <https://www.swarmia.com/blog/a-complete-guide-to-code-reviews/>
+- <https://rewind.com/blog/best-practices-for-reviewing-pull-requests-in-github/>

docs/contributing/pull-request-guidelines/review-tips.md

@@ -1,12 +1,10 @@
-# Tips
-
-This page introduces tips around pull requests or reviews.
+# Review tips
 
 ## Toggle annotations or review comments in the diff view
 
-There will be some annotations or review comments in the diff view during your review.
+There might be some annotations or review comments in the diff view during your review.
 
-Press the `A` key to toggle annotations.
+To toggle annotations, press the `A` key.
 
 Before:
 
@@ -16,16 +14,16 @@ After:
 
 ![after-press-a](images/after-press-a.png)
 
-Also, press the `I` key to toggle review comments.
+To toggle review comments, press the `I` key.
 
-Refer to [GitHub Docs](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts) for other keyboard shortcuts.
+For other keyboard shortcuts, refer to [GitHub Docs](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts).
 
 ## View code in the web-based Visual Studio Code
 
 You can open `Visual Studio Code` from your browser to view code in a rich UI.
-Press the `.` key on any repository or pull request.
+To use it, press the `.` key on any repository or pull request.
 
-Refer to [github/dev](https://github.com/github/dev) for more detailed usage.
+For more detailed usage, refer to [github/dev](https://github.com/github/dev).
 
 ## Check out the branch of a pull request quickly
 

docs/contributing/testing-guidelines/.pages

@@ -1,2 +1,4 @@
 nav:
   - index.md
+  - unit-testing.md
+  - integration-testing.md

docs/contributing/testing-guidelines/index.md

@@ -1,5 +1,21 @@
 # Testing guidelines
 
-!!! warning
+## Unit testing
 
-    Under Construction
+Unit testing is a software testing method that tests individual units of source code to determine whether they satisfy the specification.
+
+For details, see the [Unit testing guidelines](unit-testing.md).
+
+## Integration testing
+
+Integration testing combines and tests the individual software modules as a group, and is done after unit testing.
+
+While performing integration testing, the following subtypes of tests are written:
+
+1. Fault injection testing
+2. Back-to-back comparison between a model and code
+3. Requirements-based testing
+4. Anomaly detection during integration testing
+5. Random input testing
+
+For details, see the [Integration testing guidelines](integration-testing.md).