Add browser app and devcontainer setup

[planger]

What it does

This PR adds a browser app for CDT.cloud blueprint and a devcontainer setup to run it from inside a container. This container can later also be used for testing CDT.cloud blueprint without installing the OS dependencies for C/C++ development as well as for running CDT.cloud actually in a cloud infrastructure.

https://github.com/eclipse-cdt-cloud/cdt-cloud-blueprint/issues/10

Contributed on behalf of STMicroelectronics

How to test

• install the Remote Dev extension pack in VS Code
• open this repository in VS Code
• In the notification that should appear: confirm to open this folder in the remote container instead
• run yarn && yarn browser && yarn browser start
• CDT.cloud should be running on 127.0.0.1:3000 (VS Code should notify you on that)

[planger]

I like it in general! Should we first contribute something similar to the upstream Blueprint? Of course we also could do it later but it will lead to conflicts, at least initially.

I can't get the browser application to start. I tried with yarn && yarn browser build && yarn browser start in the VS Code terminal but I get errors regarding drivelist.

Error: Module did not self-register: '/workspaces/cdtcloud-blueprint/node_modules/drivelist/build/Release/drivelist.node'. at Object.Module._extensions..node (internal/modules/cjs/loader.js:1057:18)

Also building/rebuilding the native modules did not work, i.e. npx theia rebuild:electron/browser did not help.

Hm, I didn't build the electron app first, but directly built the new browser app on a clean git repo. So that's probably a difference. Did you try running yarn clean before running the scripts for building the browser app first.

[sdirix]

I did a full clean (git clean -dfx) but still run into this problem with yarn && yarn browser build && yarn browser start within the container. Can you verify that it works for you?

[planger]

I did a full clean (git clean -dfx) but still run into this problem with yarn && yarn browser build && yarn browser start within the container. Can you verify that it works for you?

You are right, thanks for testing! After doing a git clean I had the same situation. I now adjusted and harmonized the scripts and retested with electron and browser. For me they now work after a yarn && yarn browser start or yarn && yarn electron start. Can you please retry?

Thanks!

[planger]

No I didn't test the server. I assumed, just starting it and have it up and running (as it seemingly does) would suffice. :man_shrugging:

[planger]

I guess the extension tries to start the trace server itself but looks at a wrong path? Anyway, it shouldn't even need to start it, because as you suggested, the server is started up on container start now (see devcontainer file line 43):

"postStartCommand": "nohup bash -c 'yarn tracecompass-server:start &'"

[sdirix]

I guess the extension tries to start the trace server itself but looks at a wrong path? Anyway, it shouldn't even need to start it, because as you suggested, the server is started up on container start now (see devcontainer file line 43):

I think it only tries to start it in case it doesn't find it on port 8080 (default port it looks for).

[planger]

So I double-checked this now. It looks like trace compass directly accesses the trace compass server from the frontend and not via a Theia backend extension (as I would have expected).

That means, port 8080 needs to be exposed (see change efe9c9a).

Trace compass server was already running fine and listening to the port inside of the container:

node ➜ /workspaces/cdt-cloud-blueprint (issues/10 ✗) $ netstat -ltnp @ grep -w ':8080'
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      557/java  

However, I thought it was just being talked to from the Theia backend (inside of the container) and not from the browser frontend (outside of the container).