GT-Gen Core

Overview

GtGenCore is a C++ library designed to serve as a foundational component in building environment simulators for autonomous driving.

Features

1. Core Simulation Component: integration with other components to build diverse simulation systems.
2. Core functionalities: simulation controls, cenvironment creation, entity creation and build-in entity controllers
3. Modular architecture, extensibility and scalability
4. Integration with Foxglove

Getting Started

Prerequisites

1. Bazel
   • Install Bazel: https://bazel.build/install
   • Install Bazel Command-Line Completion : https://bazel.build/install/completion
   • Bazel formatter: https://github.com/bazelbuild/buildtools/blob/master/buildifier/README.md
2. C++ build environment
3. Third-party can be found in third_party

Build and Run Unit-tests

# Build and test in the debug mode
bazel build --config=core  //Core/...
bazel test --config=core //Core/...

# Build and test in the release mode
bazel build --config=core_release  //Core/...
bazel test  --config=core_release  //Core/...

# Run sanitizer checks
bazel build --config=core_san  //Core/...
bazel test  --config=core_san  //Core/...

Developer Notes

Pre-Merge Checks

The style_and_lint_checks step in the CI job ensures code quality and consistency. It perform a series of checks on each merge request. Checks Included:

1. clang-format checks
2. bazel buildifier checks
3. shell script formatting

Use script locally:

1. Prerequisites: ensure have the necessary tools installed: see dockerfile
2. Run the script locally:

   ./utils/ci/scripts/check_and_fix/check_and_fix.sh

Code-coverage

The code-coverage report can be accessed at the following link: code-coverage report. This report is automatically updated after each commit is merged into the main branch and is also included in the artifacts for each tagged release.

To generate the code-coverage report locally, you can find the report under bazel-coverage/index.html by following the instructions below:

Use script locally:

• For native Linux systems:

./utils/ci/scripts/build_and_test/code_coverage.sh

Tests Report

Access the detailed Tests report at the following link: test report. This report summarises the outcomes of unit tests, including counts of passed, failed, disabled, and errored tests, alongside total execution time. This report is automatically updated after each commit is merged into the main branch and is also included in the artifacts for each tagged release.

Use script locally:

To generate the test locally, you can find the report under test_results.html by following the instructions below:

• For native Linux systems:

./utils/ci/scripts/build_and_test/generate_test_report.sh

Versioning

Versioning should follow the Semantic Versioning pattern MAJOR.MINOR.PATCH. Currently this is a manual task that needs to be approved as a part of a code review. In the following, a coarse guideline is given for when to increment the according fields:

Major: Even small changes to a public header will most likely result in an increase of this number if they are breaking changes. As this is probably the most common case, MAJOR will therefore be incremented relatively frequently compared to other libraries.

Minor: This increments, if changes are ABI compatible, i.e. independent of the rest of other mantle definitions. It is expected that this does not happen very often at the current state of development. This includes features related to testing, such as enhancing mocks, adding tests, etc., and features related to chore tasks, such as CI scripts, CMake enhancements, formatters, etc.

Patch: This increments for tasks such as fixing typos in the documentation (as long as they don't change the semantic of a function call!), fixing bugs related to testing, and fixing bugs related to chore tasks.

Commit Message

Commit messages should follow the guidelines from Conventional Commits.

Type: The commit messages are prefixed with a type descriptor that communicates the type of change. The following is a summary of the possible types for a commit.

1. feat: introduces a new feature to the codebase (this correlates with MINOR in Semantic Versioning).
2. fix: patches a bug in the codebase (this correlates with PATCH in Semantic Versioning).
3. Appending ! after the type/scope specifies that it introduces a breaking API change (correlating with MAJOR in Semantic Versioning).
4. chore: indicates no production code changes. These are typically maintenance tasks. Subtypes can be added: chore(build):, chore(ci):, chore(style):
5. Other types can also be used: test:, docs:, perf:, refactor:

Footer (optional) Any additional information about the commit, such as referencing issue tracker IDs.