diff --git a/.codeclimate.yml b/.codeclimate.yml index de8c1ce5f..144f6c2fe 100644 --- a/.codeclimate.yml +++ b/.codeclimate.yml @@ -20,7 +20,7 @@ plugins: fixme: enabled: true markdownlint: - enabled: true + enabled: true shellcheck: enabled: true diff --git a/.mdl_style.rb b/.mdl_style.rb new file mode 100644 index 000000000..ba34fb48e --- /dev/null +++ b/.mdl_style.rb @@ -0,0 +1,4 @@ +all +rule 'MD013', :ignore_code_blocks => true +rule 'MD013', :tables => false +rule 'MD046', :indented => true diff --git a/.mdlrc b/.mdlrc index 5fbe502bd..1f82ca2ce 100644 --- a/.mdlrc +++ b/.mdlrc @@ -1,5 +1 @@ -git_recurse true -all -rule 'MD013', :ignore_code_blocks => true -rule 'MD013', :tables => false -rule 'MD046', :indented \ No newline at end of file +style '.mdl_style.rb' diff --git a/deploy/README.md b/deploy/README.md index 9ab28fc28..143843c4b 100644 --- a/deploy/README.md +++ b/deploy/README.md @@ -114,4 +114,4 @@ You can run this script multiple times until the installation is successful. ## Access the application -Now you should be able to access the DTaaS application at: _https://foo.com_ +Now you should be able to access the DTaaS application at: _https://foo.com_ diff --git a/docs/developer/index.md b/docs/developer/index.md new file mode 100644 index 000000000..0b4e2b2f5 --- /dev/null +++ b/docs/developer/index.md @@ -0,0 +1,71 @@ +# A Developer's Guide + +This guide is to help developers get familiar with the project. Please see +developer-specific +[Slides](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/DTaaS-overview.pdf), +[Video](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/DTaaS-overview.mkv), +and [Research paper](https://arxiv.org/abs/2305.07244). + +## Operating Softwares + +Ideally, developers should work on Ubuntu/Linux. Other operating systems are not supported inherently and may require additional steps. + +## Code Editing + +Any popular code editors can be used to work on the project. VS Code, Sublime Text are a few examples. + +## Development Workflow + +To manage collaboration by multiple developers on the software, a simple [Fork, Branch, PR](https://gun.io/news/2017/01/how-to-github-fork-branch-and-pull-request/) development workflow is in place. Each developer should follow these steps: + +1. Have an updated fork of the main repository on their account. This should also be added to codeclimate. +1. Clone your personal fork onto your computer. + ``` + git clone https://github.com//DTaaS.git + ``` +1. Work on your issue/feature on your personal computer. + +1. Any updates/additions to the software should first be committed to your personal fork. + + 1. To check status of your changes: + ``` + git status + ``` + 2. Add the changes to the commit: + ``` + git add --all * + ``` + 3. Finally, commit these to the repository on your PC. + ``` + git commit -m + ``` +1. Push any commits onto your fork of the repository + ``` + git push + ``` + +1. Any issues that arise codeclimate should also be resolved. + +1. Once changes are made, they should be tested on personal systems or the [integration server](https://github.com/INTO-CPS-Association/DTaaS/wiki/DTaaS-Integration-Server) . + +1. Once changes are verified, a PR should be made to the appropriate branch of the main repository. +1. Any issues raised in the PR review should be resolved. +1. Finally, the PR will be merged. + +Remember that every commit should be meaningful and satisfies the requirements. + +## Code Quality + +Quality checks are performed by CodeClimate to ensure the best possible quality of code to add to our project. + +While any new issues introduced in your code would be shown in the PR page itself, to address any specific issue, you can visit the Issues or Code section of the CodeClimate page. + +It is highly recommended that any code you add does not introduce new quality issues. If they are introduced, they should be fixed immediately using the appropriate suggestions from CodeClimate, or in worst case, adding a ignore flag (To be used with caution). + +## Testing + +For information about testing and workflow related to that, please see the [testing page](testing/intro.md). + +## Live Demo Server + +A demo server is up and running at [https://sandbox.cps.digit.au.dk/](https://sandbox.cps.digit.au.dk/). Developers will need credentials to log in. diff --git a/docs/developer/servers/lib/lib-class.mmd b/docs/developer/servers/lib/lib-class.mmd new file mode 100644 index 000000000..93eed3779 --- /dev/null +++ b/docs/developer/servers/lib/lib-class.mmd @@ -0,0 +1,46 @@ +classDiagram + class FilesResolver { + -filesService: IFilesService + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class FilesServiceFactory { + -configService: ConfigService + -gitlabFilesService: GitlabFilesService + -localFilesService: LocalFilesService + +create(): IFilesService + } + + class GitlabFilesService { + -configService: ConfigService + -parseArguments(path: string): Promise + -sendRequest(query: string): Promise + -executeQuery(path: string, getQuery: QueryFunction): Promise + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class LocalFilesService { + -configService: ConfigService + -getFileStats(fullPath: string, file: string): Promise + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class ConfigService { + +get(propertyPath: string): any + } + + class IFilesService{ + listDirectory(path: string): Promise + readFile(path: string): Promise + } + + IFilesService <|-- FilesResolver: uses + IFilesService <|.. GitlabFilesService: implements + IFilesService <|.. LocalFilesService: implements + IFilesService <|-- FilesServiceFactory: creates + ConfigService <|-- FilesServiceFactory: uses + ConfigService <|-- GitlabFilesService: uses + ConfigService <|-- LocalFilesService: uses \ No newline at end of file diff --git a/docs/developer/servers/lib/lib-sequence.mmd b/docs/developer/servers/lib/lib-sequence.mmd new file mode 100644 index 000000000..68d95b654 --- /dev/null +++ b/docs/developer/servers/lib/lib-sequence.mmd @@ -0,0 +1,99 @@ +sequenceDiagram + actor Client + actor Traefik + + box LightGreen RAMS + participant FR as FilesResolver + participant FSF as FilesServiceFactory + participant CS as ConfigService + participant IFS as IFilesService + participant LFS as LocalFilesService + participant GFS as GitlabFilesService + end + + participant FS as Local File System DB + participant GAPI as GitLab API DB + + Client ->> Traefik : HTTP request + Traefik ->> FR : GraphQL query + activate FR + + FR ->> FSF : create() + activate FSF + + FSF ->> CS : getConfiguration("MODE") + activate CS + + CS -->> FSF : return configuration value + deactivate CS + + alt MODE = Local + FSF ->> FR : return filesService (LFS) + deactivate FSF + + FR ->> IFS : listDirectory(path) or readFile(path) + activate IFS + + IFS ->> LFS : listDirectory(path) or readFile(path) + activate LFS + + LFS ->> CS : getConfiguration("LOCAL_PATH") + activate CS + + CS -->> LFS : return local path + deactivate CS + + LFS ->> FS : Access filesystem + alt Filesystem error + FS -->> LFS : Filesystem error + LFS ->> LFS : Throw new InternalServerErrorException + LFS -->> IFS : Error + else Successful file operation + FS -->> LFS : Return filesystem data + LFS ->> IFS : return Promise + end + deactivate LFS + else MODE = GitLab + FSF ->> FR : return filesService (GFS) + %%deactivate FSF + + FR ->> IFS : listDirectory(path) or readFile(path) + activate IFS + + IFS ->> GFS : listDirectory(path) or readFile(path) + activate GFS + + GFS ->> GFS : parseArguments(path) + GFS ->> GFS : executeQuery() + + GFS ->> CS : getConfiguration("GITLAB_API_URL", "GITLAB_TOKEN") + activate CS + + CS -->> GFS : return GitLab API URL and Token + deactivate CS + + GFS ->> GAPI : sendRequest() + alt GitLab API error + GAPI -->> GFS : API error + GFS ->> GFS : Throw new Error("Invalid query") + GFS -->> IFS : Error + else Successful GitLab API operation + GAPI -->> GFS : Return API response + GFS ->> IFS : return Promise + end + deactivate GFS + end + + alt Error thrown + IFS ->> FR : return Error + deactivate IFS + FR ->> Traefik : return Error + Traefik ->> Client : HTTP error response + else Successful operation + IFS ->> FR : return Promise + deactivate IFS + FR ->> Traefik : return Promise + Traefik ->> Client : HTTP response + end + + deactivate FR diff --git a/docs/developer/system/architecture.md b/docs/developer/system/architecture.md new file mode 100644 index 000000000..797514e0a --- /dev/null +++ b/docs/developer/system/architecture.md @@ -0,0 +1,102 @@ +# System Overview + +## User Requirements + +The DTaaS software platform users expect a single platform +to support the complete DT lifecycle. To be more precise, the platform users expect the following features: + +1. **Author** – create different assets of the DT on the +platform itself. This step requires use of some software +frameworks and tools whose sole purpose is to author +DT assets. +1. **Consolidate** – consolidate the list of available DT assets +and authoring tools so that user can navigate the library +of reusable assets. This functionality requires support +for discovery of available assets. +1. **Configure** – support selection and configuration of +DTs. This functionality also requires support for validation of a given configuration. +1. **Execute** – provision computing infrastructure on demand to support execution of a DT. +1. **Explore** – interact with a DT and explore the results +stored both inside and outside the platform. Exploration +may lead to analytical insights. +1. **Save** – save the state of a DT that’s already in the +execution phase. This functionality is required for ondemand saving and re-spawning of DTs. +1. **What-if analysis** – explore alternative scenarios to (i) +plan for an optimal next step, (ii) recalibrate new DT +assets, (iii) automated creation of new DTs or their +assets; these newly created DT assets may be used to +perform scientifically valid experiments. +1. **Share** – share a DT with other users of their organisation. + +## System Architecture + +![System architecture](architecture.png) + +## System Components + +The figure shows the system architecture of the the DTaaS software platform. The main domains of this architecture are: + +1. [The Website](./client.md) + +1. [The Gateway](https://github.com/INTO-CPS-Association/DTaaS/tree/feature/distributed-demo/servers/config/gateway#the-gateway-server) - This is the single point of entry for direct access to the platform services. The gateway is responsible for controlling user access to the microservice components. + +1. [The Library Microservice (Reusable Assets)](./lib-ms.md) + +### Microservices + +1. **The security microservice** implements +role-based access control (RBAC) in the platform. +1. **The accounting microservice** is responsible for keeping track of the +platform, DT asset and infrastructure usage. Any licensing, +usage restrictions need to be enforced by the accounting +microservice. Accounting is a pre-requisite to commercialisation of the platform. +Due to significant use of external +infrastructure and resources via the platform, the accounting +microservice needs to interface with accounting systems of +the external services. +1. **The data microservice** is a frontend to all the databases +integrated into the platform. A time-series database and a +graph database are essential. These two databases store timeseries +data from PT, events on PT/DT, commands sent by +DT to PT. The PTs uses these databases even when their +respective DTs are not in the execute phase. +1. **The visualisation microservice** is again a frontend to +visualisation software that are natively supported inside the platform. +Any visualisation software running either on external +systems or on client browsers do not need to interact with +this microservice. They can directly use the data provided by +the data microservice. + +## C4 Architectural Diagrams + +The C4 architectural diagrams of the DTaaS software are presented here. + +### Level 1 + +This Level 1 diagram only shows the users and the roles they play in the DTaaS software. + +![Alt text](c4l1.png) + +### Level 2 + +This Level 2 diagram shows the software containers of the DTaaS software. + +![Detailed C4 architecture](c4l3.png) + +A mapping of containers to system components is also available in the table. + +| System Component | Container(s) | +|:---|:---| +| Gateway | Service Router | +| Unified Interface | React Webapplication | +| Reusable Assets | Library Microservice | +| Data | MQTT, InfluxDB, and RabbitMQ (not shown in the C4 Level 2 diagram) | +| Visualization | InfluxDB (not shown in the C4 Level 2 diagram) | +| DT Lifecycle | DT Lifecycle Manager and DT Configuration Validator | +| Security | Gitlab | +| Accounting | None | +| Execution Manager | Execution Manager | + +## Disclaimer +Only the web client and library microservice components are functional at present. +Everything else is a work-in-progress. \ No newline at end of file diff --git a/docs/developer/system/architecture.png b/docs/developer/system/architecture.png new file mode 100644 index 000000000..ae1ad2d46 Binary files /dev/null and b/docs/developer/system/architecture.png differ diff --git a/docs/developer/system/c4l1.png b/docs/developer/system/c4l1.png new file mode 100644 index 000000000..bb981411d Binary files /dev/null and b/docs/developer/system/c4l1.png differ diff --git a/docs/developer/system/c4l3.png b/docs/developer/system/c4l3.png new file mode 100644 index 000000000..13b1099cc Binary files /dev/null and b/docs/developer/system/c4l3.png differ diff --git a/docs/developer/system/client.md b/docs/developer/system/client.md new file mode 100644 index 000000000..019e9149d --- /dev/null +++ b/docs/developer/system/client.md @@ -0,0 +1,9 @@ +# Website + +The [Website](https://github.com/INTO-CPS-Association/DTaaS/tree/feature/distributed-demo/client#readme) is how the end-users interact with the software platform. + +This is the Client side (frontend) for Digital Twin as a Service (DTaaS) software. The software provides a React single page web application for the Digital Twin support platform. + +## Client Architecture + +![Client architecture](package-diagram.png) \ No newline at end of file diff --git a/docs/developer/system/lib-ms.md b/docs/developer/system/lib-ms.md new file mode 100644 index 000000000..53175fa7a --- /dev/null +++ b/docs/developer/system/lib-ms.md @@ -0,0 +1,162 @@ +# Library Microservice + +[The Library Microservices](https://github.com/INTO-CPS-Association/DTaaS/tree/feature/distributed-demo/servers/lib#readme) - fulfil the core requirements of the system. The microservices are complementary and composable. + +The service mesh enables discovery of microservices, load balancing and authentication functionalities. There are microservices for catering to author, store, explore, configure, execute and scenario analysis requirements. + +## Lib-MS Architecture + +### Class Architecture +```mermaid +classDiagram + class FilesResolver { + -filesService: IFilesService + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class FilesServiceFactory { + -configService: ConfigService + -gitlabFilesService: GitlabFilesService + -localFilesService: LocalFilesService + +create(): IFilesService + } + + class GitlabFilesService { + -configService: ConfigService + -parseArguments(path: string): Promise + -sendRequest(query: string): Promise + -executeQuery(path: string, getQuery: QueryFunction): Promise + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class LocalFilesService { + -configService: ConfigService + -getFileStats(fullPath: string, file: string): Promise + +listDirectory(path: string): Promise + +readFile(path: string): Promise + } + + class ConfigService { + +get(propertyPath: string): any + } + + class IFilesService{ + listDirectory(path: string): Promise + readFile(path: string): Promise + } + + IFilesService <|-- FilesResolver: uses + IFilesService <|.. GitlabFilesService: implements + IFilesService <|.. LocalFilesService: implements + IFilesService <|-- FilesServiceFactory: creates + ConfigService <|-- FilesServiceFactory: uses + ConfigService <|-- GitlabFilesService: uses + ConfigService <|-- LocalFilesService: uses +``` + +### Sequence Architecture + +```mermaid +sequenceDiagram + actor Client + actor Traefik + + box LightGreen Library Microservice + participant FR as FilesResolver + participant FSF as FilesServiceFactory + participant CS as ConfigService + participant IFS as IFilesService + participant LFS as LocalFilesService + participant GFS as GitlabFilesService + end + + participant FS as Local File System DB + participant GAPI as GitLab API DB + + Client ->> Traefik : HTTP request + Traefik ->> FR : GraphQL query + activate FR + + FR ->> FSF : create() + activate FSF + + FSF ->> CS : getConfiguration("MODE") + activate CS + + CS -->> FSF : return configuration value + deactivate CS + + alt MODE = Local + FSF ->> FR : return filesService (LFS) + deactivate FSF + + FR ->> IFS : listDirectory(path) or readFile(path) + activate IFS + + IFS ->> LFS : listDirectory(path) or readFile(path) + activate LFS + + LFS ->> CS : getConfiguration("LOCAL_PATH") + activate CS + + CS -->> LFS : return local path + deactivate CS + + LFS ->> FS : Access filesystem + alt Filesystem error + FS -->> LFS : Filesystem error + LFS ->> LFS : Throw new InternalServerErrorException + LFS -->> IFS : Error + else Successful file operation + FS -->> LFS : Return filesystem data + LFS ->> IFS : return Promise + end + deactivate LFS + else MODE = GitLab + FSF ->> FR : return filesService (GFS) + %%deactivate FSF + + FR ->> IFS : listDirectory(path) or readFile(path) + activate IFS + + IFS ->> GFS : listDirectory(path) or readFile(path) + activate GFS + + GFS ->> GFS : parseArguments(path) + GFS ->> GFS : executeQuery() + + GFS ->> CS : getConfiguration("GITLAB_API_URL", "GITLAB_TOKEN") + activate CS + + CS -->> GFS : return GitLab API URL and Token + deactivate CS + + GFS ->> GAPI : sendRequest() + alt GitLab API error + GAPI -->> GFS : API error + GFS ->> GFS : Throw new Error("Invalid query") + GFS -->> IFS : Error + else Successful GitLab API operation + GAPI -->> GFS : Return API response + GFS ->> IFS : return Promise + end + deactivate GFS + end + + alt Error thrown + IFS ->> FR : return Error + deactivate IFS + FR ->> Traefik : return Error + Traefik ->> Client : HTTP error response + else Successful operation + IFS ->> FR : return Promise + deactivate IFS + FR ->> Traefik : return Promise + Traefik ->> Client : HTTP response + end + + deactivate FR + +``` diff --git a/docs/developer/system/package-diagram.png b/docs/developer/system/package-diagram.png new file mode 100644 index 000000000..bf2a0996d Binary files /dev/null and b/docs/developer/system/package-diagram.png differ diff --git a/docs/developer/testing/intro.md b/docs/developer/testing/intro.md new file mode 100644 index 000000000..3a5130c9d --- /dev/null +++ b/docs/developer/testing/intro.md @@ -0,0 +1,41 @@ +# Testing + +## What is Software Testing? +Software testing is a procedure to investigate the quality of a software product in different scenarios. It can also be stated as the process of verifying and validating that a software program or application works as expected and meets the business and technical requirements that guided design and development. + +### Why Software Testing? +Software testing is required to point out the defects and errors that were made during different development phases. Software testing also ensures that the product under test works as expected in all different cases – stronger the test suite, stronger is our confidence in the product that we have built. One important benefit of software testing is that it facilitates the developers to make incremental changes to source code and make sure that the current changes are not breaking the functionality of the previously existing code. + +### What is TDD? +TDD stands for “Test Driven Development”. It is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. The goal of TDD can be viewed as specification and not validation. In other words, it’s one way to think through your requirements or design before your write your functional code. + +### What is BDD? +BDD stands for “Behaviour Driven Development”. It is a software development process that emerged from TDD. It includes the practice of writing tests first, but focuses on tests which describe behavior, rather than tests which test a unit of implementation. This provides software development and management teams with shared tools and a shared process to collaborate on software development. BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes. Mocha and Cucumber are built around the concepts of BDD. + +# Testing workflow + +We follow a testing workflow in accordance with [The Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid), starting with isolated tests and moving towards complete integration for any new feature changes. The different types of tests (in the order that they should be performed) are explained below: + +## [Unit Tests](https://martinfowler.com/articles/practical-test-pyramid.html#UnitTests) + +Unit testing is a level of software testing where individual units/ components of a software are tested. The objective of Unit Testing is to isolate a section of code and verify its correctness. + +Ideally, each test case is independent from the others. Substitutes such as method stubs, mock objects, and spies can be used to assist testing a module in isolation. + +### Benefits of Unit Testing +* Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. +* If codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less. +* The cost, in terms of time, effort and money, of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. + +## [Integration tests](https://martinfowler.com/articles/practical-test-pyramid.html#IntegrationTests) + +Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. In DTaaS, we use an [integration server](https://github.com/INTO-CPS-Association/DTaaS/wiki/DTaaS-Integration-Server) for software development as well as such tests. + +## Feature Tests + +A Software feature can be defined as the changes made in the system to add new functionality or modify the existing functionality. Each feature is said to have a characteristics that is designed to be useful, intuitive and effective. It is important to test a new feature when it has been added. We also need to make sure that it does not break the functionality of already existing features. Hence feature tests prove to be useful. + +## [End-to-End tests](https://martinfowler.com/articles/practical-test-pyramid.html#End-to-endTests) + +Testing any code changes through the end user interface of your software is essential to verify if your code has the desired effect for the user. [End-to-End tests in DTaaS](https://github.com/INTO-CPS-Association/DTaaS/blob/feature/distributed-demo/client/test/README.md) a functional setup. For more information [visit here](https://github.com/INTO-CPS-Association/DTaaS/blob/feature/distributed-demo/client/test/README.md). + diff --git a/docs/index.md b/docs/index.md index 81cfa941f..46d418824 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,18 +1,14 @@ +# What is DTaaS + The Digital Twin as a Service (DTaaS) software is useful to create and run digital twins. The digital twins that are running can be used as service by other users. -These users need not be members of the DTaaS software platform itself. - -There is an overview of the software available for: - -* General users : [overview slides](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/DTaaS-short-intro.pdf) - and [overview video](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/DTaaS-short-intro.mp4), - [feature walkthrough](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/dtaas-v0.2.0-demo.mp4) -* Developers : [slides](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/DTaaS-overview.pdf) - and [video](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/DTaaS-overview.mkv). +These users of digital twins need not be members of the DTaaS software platform itself. -There is also a [research paper draft](https://arxiv.org/abs/2305.07244) -if you are interested in reading the scientific roadmap for this software. +There is an overview of the software available in the form of +[slides](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/DTaaS-short-intro.pdf), +[video](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/DTaaS-short-intro.mp4), +and [feature walkthrough](https://odin.cps.digit.au.dk/into-cps/dtaas/assets/videos/dtaas-v0.2.0-demo.mp4). ## License diff --git a/docs/user/workflow.png b/docs/user/workflow.png new file mode 100644 index 000000000..c24f5b805 Binary files /dev/null and b/docs/user/workflow.png differ diff --git a/mkdocs-github.yml b/mkdocs-github.yml index 0224f1b3b..c3a4ff876 100644 --- a/mkdocs-github.yml +++ b/mkdocs-github.yml @@ -27,6 +27,14 @@ nav: - Separate Packages: - website: admin/client/CLIENT.md - library microservice: admin/servers/lib/LIB-MS.md + - Developer: + - System: + - Architecture: developer/system/architecture.md + - Library Microservice: developer/system/lib-ms.md + - Client: developer/system/client.md + - Testing: + - Introduction: developer/testing/intro.md + - Index: developer/index.md - User: - Features: user/features.md - Website: user/website/index.md @@ -38,6 +46,13 @@ nav: - Lifecycle: user/digital-twins/lifecycle.md - Examples: https://github.com/INTO-CPS-Association/DTaaS-examples - FAQ: FAQ.md + - Developer: + - Overview: developer/index.md + - System: + - Architecture: developer/system/architecture.md + - Library Microservice: developer/system/lib-ms.md + - Client: developer/system/client.md + - Testing: developer/testing/intro.md - Bugs: bugs.md - Thanks: thanks.md - License: LICENSE.md @@ -63,13 +78,22 @@ markdown_extensions: pygments_lang_class: true - pymdownx.inlinehilite - pymdownx.snippets - - pymdownx.superfences + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format - pymdownx.details - admonition - pymdownx.tabbed: alternate_style: true - mdx_math: enable_dollar_delimiter: True + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format plugins: - open-in-new-tab diff --git a/mkdocs.yml b/mkdocs.yml index 615674e7b..e7c4f289b 100755 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -38,6 +38,13 @@ nav: - Lifecycle: user/digital-twins/lifecycle.md - Examples: https://github.com/INTO-CPS-Association/DTaaS-examples - FAQ: FAQ.md + - Developer: + - Overview: developer/index.md + - System: + - Architecture: developer/system/architecture.md + - Library Microservice: developer/system/lib-ms.md + - Client: developer/system/client.md + - Testing: developer/testing/intro.md - Bugs: bugs.md - Thanks: thanks.md - License: LICENSE.md @@ -63,13 +70,22 @@ markdown_extensions: pygments_lang_class: true - pymdownx.inlinehilite - pymdownx.snippets - - pymdownx.superfences + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format - pymdownx.details - admonition - pymdownx.tabbed: alternate_style: true - mdx_math: enable_dollar_delimiter: True + - pymdownx.superfences: + custom_fences: + - name: mermaid + class: mermaid + format: !!python/name:pymdownx.superfences.fence_code_format plugins: - open-in-new-tab