Dev Tools

This is a collection of Luminar's development tools. These tools are used to help developers in their day-to-day tasks.

• Tools
  • Configure VS Code for Bazel
  • Whoowns
• Hooks
  • check-build-file-without-extensions
  • check-snake-case
  • check-cpp-and-cu-unit-test-naming-pattern
  • check-no-dashes
  • check-sys-path-append
  • go-fmt
  • go-imports
  • go-revive
  • generate-hook-docs
  • check-number-of-lines-count
  • check-shellscript-set-options
  • check-jira-reference-in-todo
  • check-non-existing-and-duplicate-excludes
  • print-pre-commit-metrics
  • sync-vscode-config
  • check-ownership
• Contributing

Tools

Configure VS Code for Bazel

If you want to work with C++ Bazel targets in VS Code, you can use configure-vscode-for-bazel to generate a VS Code configuration. This tool supports generating:

• .vscode/launch.json and tasks.json files that contain selected targets for debugging and compiling in VS Code and
• a compile_commands.json file using bazel-compile-commands-extractor for selected targets.

To generate these for a defined set of targets, run

configure-vscode-for-bazel //path/to/your/target/...

This will be forwarded to a bazel query listing all cc_binary and cc_test targets. Then, when you go to VSCode -> Run and Debug (Ctrl+Shift+D) you'll be able to select an executable. By pressing ▶ Start Debugging (F5), you'll trigger a bazel build command and start debugging the executable. The latter is provided by C/C++ Microsoft extension.

Make sure you compile with debug symbols (--compilation_mode=dbg) enabled. You can pass your Bazel flags to this tool with --additional-debug-arg.

In addition, a .vscode/BUILD.bazel file will be created and bazel-compile-commands-**extractor** run to create a compile_commands.json in the workspace root. See the usage documentation for more information.

Whoowns

whoowns is a tool to print the GitHub codeowner of a folder or file by parsing the .github/CODEOWNERS file. With this tool, you can easily find out who is responsible for a specific part of the codebase from the terminal. To find the owners of a file or folder, run

whoowns path/to/your/file/or/folder

# example output
# path/to/your/file/or/folder -> @owner1

Specify the --level N to see the owners of child items in the N-th directory level below your provided folder.

Hooks

check-build-file-without-extensions

Check that BUILD files have a .bazel ending. BUILD.bazel file is the recommended way to name these files.

check-snake-case

Check that all source code files are snake_case. We don't want to use camelCase or kebab-case file names.

check-cpp-and-cu-unit-test-naming-pattern

Check that all C++ and Cuda unit test files end with _test.cpp or _test.cu (no _tests) and that they're under a /tests/ folder (not /test/).

check-no-dashes

Check that markdown filenames do not use dashes

check-sys-path-append

Check that no sys.path.append is used in Python code

go-fmt

Format go files

go-imports

Order go imports

go-revive

Run Go Revive linter

generate-hook-docs

Generate markdown documentation from the hook descriptions in .pre-commit-hooks.yaml into the README.md. Docs are generated between hooks-doc start and hooks-doc end markdown comment blocks.

check-number-of-lines-count

Check that number of lines in scripts do not exceed max-lines. Use --max-lines=<number> to set the maximum number of lines. Default is 30 for shell scripts.

check-shellscript-set-options

Check if options are set with set -euxo pipefail. Use # nolint(set_options) to ignore this check.

check-jira-reference-in-todo

Check that all TODO comments follow the same pattern and link a Jira ticket: TODO(ABC-1234):.

check-non-existing-and-duplicate-excludes

Check for non existing and duplicate paths in .pre-commit-config.yaml.

Background: In a big codebase, the exclude lists can be quite long and it's easy to make a typo or forget to remove an entry when it's no longer needed. This hook helps you to maintain a clean and up to date exclude list.

print-pre-commit-metrics

Count the number of excludes in .pre-commit-config.yaml and print them in json format.

On large projects this can help to collect metrics over time for how many files are excluded from pre-commit.

sync-vscode-config

Sync VSCode settings and extensions from devcontainer.json to .vscode folder. devcontainer.json will be now your source of truth. Entries defined in settings.json and extensions.json which don't exist in devcontainer.json will be left as is.

If settings.json and extensions.json are ignored in Git, consider running the hook in post-checkout and post-merge stages by overwriting the stages config. In this case, define your default_install_hook_types in the pre-commit config and set always_run: true for this hook.

check-ownership

Check if all folders in the CODEOWNERS file exist, there are no duplicates, and it has acceptable codeowners.

What is an acceptable codeowner? We want to make sure that every folder has a codeowner other than the team that should exclusively own the CODEOWNERS file. For this, we define a CODEOWNERS_OWNER using the --codeowners-owner argument. Your CODEOWNERS file should look as follows:

* CODEOWNERS_OWNER

# Here goes all your CODEOWNERS file content overriding the wildcard owner

# leave this at the bottom to have highest ownership priority
/.github/CODEOWNERS CODEOWNERS_OWNER

If the hook detects CODEOWNERS_OWNER owns anything else than .github/CODEOWNERS it will fail to make sure every file added has an acceptable codeowner.

Contributing

Please refer to the CONTRIBUTING.md file for information on how to contribute to this project.