Initial set-up of Tooling

[antonkri]

Introduce following tooling (we probably need a separate sub-issue for every item)

• All checks for requirements and architectural elements (linking, obligatoric attributes)
• Open Source Software Scan
• Contribution Request: how to deal with modules in a separate repo
• Contribution Request: Misra/Autosar checks with clang-tidy.

[AlexanderLanin]

Here is a more detailed list of "initial tooling". For planning purposes we could create separate sub-issues.

Infrastructure:

• Repositories, branch conventions & protections, CODEOWNERS (-> otterdog)
• Multi-repo approach for code (-> bazel)
• Prepare PR checks
• Perform (continuous) OSS scans
• prepare toolchains, incl docs, for usage in multiple repositories

Docs (Sphinx, Sphinx-Needs):

• Introduce initial highlighting, preview and linting for .rst and .md files (-> esbonio) -> covered by Introduce VS Code extension #30
• Introduce initial code completion for .rst and .md files (-> templates and/or sphinx-needs extension) -> covered by 30
• Introduce first checks like mandatory attributes (-> pydantic based metamodel) < partially blocked by Initial version of Software Dev Process #39 (expected Jan 2025). But we can start with the basics etc.
• Enable drawing images (-> plantuml, mermaid and/or drawio)
• Extend meta model with first few elements
• Initial support for the first multi-repo use cases

C++:

• Prepare any C++ compiler/toolchain
• Best guess coding rules
• Best guess tooling (static code analysis, formatting)

Rust:

• Prepare rust compiler/toolchain
• Best guess coding rules
• Best guess tooling (static code analysis, formatting)

Python:

• Best guess coding rules
• Best guess tooling (static code analysis, formatting)

[ltekieli]

For the infra part:

• Repositories, branch conventions & protections, CODEOWNERS (-> otterdog)
  • -> Improvement: otterdog extended configuration with branch protection #33
• Multi-repo approach for code (-> bazel)
  • -> Improvement: Create repositories according to integration overview #18
  • -> Create bazel registry #125
  • @AlexanderLanin unless you have something else in mind?
• Prepare PR checks
  • -> Improvement: GitHub action guide #17
  • @AlexanderLanin we might not be able to prepare everything upfront, but rather based on the needs of any particular repository. But high level guidelines should at least help the developers.
• Perform (continuous) OSS scans
  • -> Setup of OSS license scanning tooling #82
• prepare toolchains, incl docs, for usage in multiple repositories
  • -> Setup documentation tooling (sphinx, sphinx-needs) #78 Setup Rust tooling #80 Setup Python guidelines #81 Setup C++ tooling #79

[AlexanderLanin]

Looks good except OSS: I have a feeling Dash is a small subset of OSS. We'll need to collect OSS (scanning) requirements.