Skip to content

Provide (almost empty) template repository for modules #511

Closed

Description

@AlexanderLanin

Provide template for C++ or Rust modules. (One or seperate template, to be discussed)

Content e.g.:

  • toolchain incl formatter, linter, syntax highlighting
  • gitlint
  • README.md
  • LICENSE.md
  • CONTRIBUTION.md
  • docs with venv
  • github actions
  • cr_checker
  • dash integration

We'll start with an almost empty template repository, and add more tools as they become ready for "reuse" as in #503

Urgent open points:

  • Are we talking about "GitHub template repositories" here or some other approach?
  • Is it 1 or 2 templates. Do we expect mixed language modules?

Activity

  1. added this to the milestone on Feb 25, 2025
  2. changed the title [-]Provide repository template for modules[/-] [+]Provide template repository for modules[/+] on Feb 25, 2025
  3. AlexanderLanin commented on Feb 27, 2025

    @AlexanderLanin
    MemberAuthor

    We can create a new one or extend the examples repository... since there is no clear opinion let's extend the examples.

    Link: https://github.com/eclipse-score/examples

    What can we do now? Most of the stuff seems blocked by other issues!

  4. changed the title [-]Provide template repository for modules[/-] [+]Provide (almost empty) template repository for modules[/+] on Mar 3, 2025
  5. dcalavrezo-qorix commented on Mar 6, 2025

    @dcalavrezo-qorix
    Contributor

    First things first, we need to summarize what should be included:

    File Description
    README.md Short description of the module/component & build instructions
    src folder containing source files
    CONTRIBUTION.md Guidelines to contribute
    LICENSE.md Licensing information
    tests Folder containing the UT and IT
    .github/workflows For integrating the CI/CD pipelines
    docs Documentation with venv
    .bazelrc, MODULE.bazel, BUILD Bazel related config & settings
    .vscode Config files for VS Code

    Tools and linters should be integrated from centralized repos.
    Based on the repo type ( RUST / C++ ), we should decide on dependency management.
    We need to clarify how to handle a centralized docs structure.

    The template should contain a basic helloworld example ( for both RUST and C++) - with documented source files and it should be buildable out of the box ( including tests, documentation).

    The set of tools that should be included has to be clarified as well.

  6. dcalavrezo-qorix commented on Mar 6, 2025

    @dcalavrezo-qorix
    Contributor

    https://github.com/dcalavrezo-qorix/cpp-template-repository

    draft created, let's review it, expand it and afterwards I will convert it to an otterdog template

  7. dcalavrezo-qorix commented on Mar 6, 2025

    @dcalavrezo-qorix
    Contributor

    ok, the template has been updated, both RUST and CPP were added.
    Also I have integrated the cr_checker tool as an external module.

    Now this has to be integrated in otterdog

  8. dcalavrezo-qorix commented on Mar 7, 2025

    @dcalavrezo-qorix
    Contributor
  9. dcalavrezo-qorix commented on Mar 10, 2025

    @dcalavrezo-qorix
    Contributor
  10. dcalavrezo-qorix commented on Mar 12, 2025

    @dcalavrezo-qorix
    Contributor

    As discussed during our calls, the template repository is an incremental work in progress.

    Open points that should be taken in consideration

    1. it's not clear if using the template actually works within otterdog, as this hasn't been tested yet. Hence its early creation.
    2. the workflows which are now part of the template, obviously do not work. For that we would need to have a centralized repo, which is handled in reusable github workflows/actions #512
    3. Also, to have the reusable workflows available, we would to have the bazel rules defined for all the required jobs ( static code analysis, building, testing, linting, etc).
    4. We don't have a bazel-rules repo defined yet. That is also a work in progress.
    5. We don't have ADRs for all the tools that will be used across different project types ( source file, ASIL requirements, etc).

    So, this is an incremental work in progress. We could theoretically discuss and plan every aspect, but I think it will take too long, or we can actually have a POC-like approach, which we can adjust later on.

  11. AlexanderLanin commented on Mar 25, 2025

    @AlexanderLanin
    MemberAuthor

    Let's create new tickets for all open points and close this one. Otherwise it's not really clear what is open.

    @dcalavrezo-qorix @nicu1989 can you create tickets for everything that is currently missing (and not planned)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions