You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Provide (almost empty) template repository for modules #511
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.
As discussed during our calls, the template repository is an incremental work in progress.
Open points that should be taken in consideration
it's not clear if using the template actually works within otterdog, as this hasn't been tested yet. Hence its early creation.
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
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).
We don't have a bazel-rules repo defined yet. That is also a work in progress.
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.
Activity
[-]Provide repository template for modules[/-][+]Provide template repository for modules[/+]AlexanderLanin commentedon Feb 27, 2025
We can create a new one or extend the
examplesrepository... 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!
[-]Provide template repository for modules[/-][+]Provide (almost empty) template repository for modules[/+]dcalavrezo-qorix commentedon Mar 6, 2025
First things first, we need to summarize what should be included:
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
helloworldexample ( 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.
dcalavrezo-qorix commentedon Mar 6, 2025
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
dcalavrezo-qorix commentedon Mar 6, 2025
ok, the template has been updated, both RUST and CPP were added.
Also I have integrated the
cr_checkertool as an external module.Now this has to be integrated in otterdog
dcalavrezo-qorix commentedon Mar 7, 2025
created draft PR
eclipse-score/.eclipsefdn#19
dcalavrezo-qorix commentedon Mar 10, 2025
eclipse-score/module_template#1
dcalavrezo-qorix commentedon Mar 12, 2025
As discussed during our calls, the template repository is an incremental work in progress.
Open points that should be taken in consideration
otterdog, as this hasn't been tested yet. Hence its early creation.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.AlexanderLanin commentedon Mar 25, 2025
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)?