Closed planger closed 2 years ago
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.
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?
I did a full clean (
git clean -dfx
) but still run into this problem withyarn && 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!
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:
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 &'"
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).
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).
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
yarn && yarn browser && yarn browser start
127.0.0.1:3000
(VS Code should notify you on that)