eclipsesource / cdtcloud-deploymentserver

cdtcloud-deploymentserver

Getting Started

Deployment Server

1. Install docker-compose
2. Run docker-compose up db
3. Install dependencies: yarn install
4. Run database migration once to initialize: yarn --cwd=packages/deployment-server run prisma migrate deploy
5. Generate DB Typings: yarn --cwd=packages/deployment-server run prisma generate
6. Seed DB: yarn --cwd=packages/deployment-server run prisma db seed
7. Start the server: yarn --cwd=packages/deployment-server run dev

GCS support

1. Set env variables

GOOGLE_CLOUD_PROJECT
GOOGLE_CLOUD_BUCKET

2. Add a .gcs_key.json in packages/deployment-server

3. Run the deployment server

Device Connector

With Docker

1. Set deployment-server URI in .docker/device-connector/env
2. Run the device-connector: docker-compose up devcon
   • Build the docker-image beforehand if necessary docker-compose build

Note: Due to docker not supporting privileged mode on Windows, this does only work on unix systems.

On System

1. Download the latest supported arduino-cli version (currently v0.20.0) from arduino-cli releases
2. Start the arduino-cli daemon: arduino-cli daemon --port 50051 --daemonize --verbose
3. Install dependencies: yarn install
4. Set deployment-server URI in packages/device-connector/.env
5. Start the device connector: yarn --cwd=packages/device-connector run start

Add support for additonal boards

STM32 Board-Core

arduino-cli config add board_manager.additional_urls https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
arduino-cli core update-index
arduino-cli core install STMicroelectronics:stm32

Arduino:sam Board-Core

arduino-cli core update-index
arduino-cli core install arduino:sam

Theia:

To configure the deployment server, set:

DEPLOYMENT_SERVER_HOST=localhost:3001 DEPLOYMENT_SERVER_SECURE=false

cdtcloud-deploymentserver's Issues

Fix Monitoring Output/ Terminal Streams [8]

Monitoring on two devices leads to output on both.

Add documentations (readme) [2]

diagrams with https://mermaid-js.github.io/mermaid/#/

[Feature]: Modularity for different device types/core support

Describe your feature request or suggestion in detail

Instead of having to change the code to specify which type of file a specific device type or core needs, this should be implemented modular.
Adding a file to specify this that automatically gets loaded from a folder using hooks solves the issue as well and is much more user friendly.
Maybe this can even be done from the Deployment Server to centralize the support and implementation.

Describe a possible solution to your feature or suggestion in detail

No response

Additional context

No response

Add license headers to all source files [1]

POC: Enable remote debugging [13]

Fix remote set-up, i.e. deploy server remotly [5]

Test and log issues, only ix super small isues right away

Animations/ Transitions in Frontend [3]

please specify details in a list

Update FrontEnd Configuration [5]

Choose Deployment Server, Target URI, Port - make it configurable
Note: Widget Settings can be used

Add CI (via Github actions)

also run on PRs

[Bug]: WebSockets lose connection after a while

Current Behaviour

WebSockets of the DeviceConnector lose the connection to a remote DeploymentServer after a certain time of inactivity.
The reason for this is the default timeout in proxies and webservers of 30 seconds.

Expected Behaviour

DeviceConnector should not disconnect and reconnect in such a short period.

Source

No response

Steps to reproduce the problem

1. Set the DeviceConnector's configuration to connect to a remote DeploymentServer
2. Watch it disconnect and reconnect

Extra Notes

The easiest workaround right now is to simply set the timeout of the webserver to a higher value.

Configuration in Nginx to set the Timeout to 1 Day:

proxy_read_timeout 86400s;
proxy_send_timeout 86400s;

However, this workaround is not a solution when using a service like Cloudflare, as they have a default timeout of 100s set. A user cannot influence this in any way (Source: stackoverflow).

A possible solution for the implementation might be to add a heartbeat to keep the connection alive and active by simply using the ping function and handling the pong answer.

Code rev. hash/commit

a09070c

Node version

16.13.0

Operating system

Ubuntu 20.04

Custom changes

None

POC: Allow observing hardware via Webcam [13]

[Bug]: deployment-server-ui Devices shows a white screen

Current Behaviour

When opening the Devices page in the deployment server frontend, nothing is displayed and the screen stays white.

Expected Behaviour

The page should show a table with the devices.

Source

No response

Steps to reproduce the problem

1. run the application
2. go to the site where deployment-server-ui is running
3. click on Devices in the sidebar

Extra Notes

No response

Code rev. hash/commit

653a1aa

Node version

16.13

Operating system

Windows 10 x64

Custom changes

No response

Support ST Board [13]

Current Behaviour
Arduino CLI does not "recognize" the STM Board.
Thus, no upload to ST Boards is possible.

Target Behaviour
ST Boards are supported the same way as Arduino Boards.
They should be recognized by the device connector, managed by the deployment server, and selectable in the theia extension for deployment.

Necessary Steps for Proof of Concept

• Test the binary upload via the STM32Progammer CLI (the idea is that the compilation part is still done via Arduino CLI)
• Incorporate the new CLI into the workflow of our Device Connector
• Possible changes in implementation for the deployment-server (Board FQBN, Database entries, ...)
• Possible changes in the Theia Extension Frontend (although this should work when the other parts work) or in the Extension Backend

Additional Features

• Serial Monitor Stream with the same behavior as the Arduino Boards.

Testing
Download STM32CubeProg from the official website and install. The CLI is located in the installation directory: "\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe"

Ressources
Documentation of STM32 Cube Programmer CLI

https://github.com/stm32duino/wiki/wiki/Upload-methods#stm32cubeprogrammer

[Documentation]: Refine readme

Describe your feature request or suggestion in detail

Step
Deployment Server => "Install dependencies: yarn install"
I assume this command is supposed to be execute in the launched docker container, isn't it?
How to run this command in the docker container?

Describe a possible solution to your feature or suggestion in detail

No response

Additional context

No response

RpcClient Overhaul [3]

align Theia RpcClient with device connector client

Review Feedback

Hi guys,

I took a look at your code, here are my remarks.

• add readme files to each sub package
• add useful extensions to the list of recommended extensions

deployment-server-ui

redux

• co-locate all redux stuff in one folder (reducers are next to the app folder which only contains the store)
• check whether your redux state is enough, especially the boolean flags like loading, maybe rather use a status with 3 states: 'loading', 'failed', 'successful'
• maybe use more of the redux/toolkit classes eg entities and thunks for retrieving the dashboard data: see https://redux-toolkit.js.org/api/createAsyncThunk, you could get rid of the setError and setData reducers that feel weird
• use optional instead of null
• maybe move data loaded in components into redux? thus also handle states etc there

generic

• remove commented out code
• double check class and interface naming, there is no need to prefix interfaces with I, some types are lowercase
• use push api on backend instead of pulling every 1-3 seconds
• move the code to App.tsx and directly use the Dashboard for the / path ?
• why use an identity function (defineFunctionalComponent) to wrap the functional component?
• split big components in smaller one eg the dashboard
• use optional chaining (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining)
• use arrow functions (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)
• use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment to directly access the properties you later need of an object
• maybe pull out common formatter functions to a common util
• rename 'services' to 'hooks' as those are react hooks

device-connector

• why the # prefix in private members

grpc

• why the partial copy?

theia-extension

• why the empty registerMenu registration?
• why the mix of got and axios in backend?

check compatibility of GPU licenses used in Arduino with EPL

Can code published under the Apache license (./packages/grpc) be used under the Eclipse Public License

Reproducible installation of full system via docker [8]

Simplify the compilation/installation as much as possible, so as a user, i can get the system running on Linux with one script.

Ubuntu 20.04

fix deployment-server-ui Devices (White screen)

[Bug]: CI Test Failing (Device-Connector)

Current Behaviour

Device-Connector CI-Test for the gRPC Client (listAllBoards) fails due to different latest core version as it is hardcoded in the expected result.

Expected Behaviour

Test should pass independent of the latest or installed core verison and instead adjust accordingly - not hardcoded

Source

No response

Steps to reproduce the problem

1. Update the arduino-cli core-indexes arduino-cli core update-index
2. Run the arduino-cli daemon as usual
3. Run the device-connector tests yarn run --cwd=packages/device-connector test

Extra Notes

No response

Code rev. hash/commit

ef57a44

Node version

v17.7.1

Operating system

Ubuntu 20.04

Custom changes

None

fix ignored lint errors in deployment-server-ui + cdtcloud

Add basic test coverage [5]

Use Correct Color Schemes [3]

e.g. Theia Color Scheme in IDE Frontend

Add issue templates to repo [1]