VisualStudio Code und Devcontainer
-
@AlCalzone said in VisualStudio Code und Devcontainer:
Das wäre dann aber ein Problem in der VSCode Implementation
Das postCreateCommand ist nämlich bewusst so gewählt, dass man nicht beim lokalen Testen das ioBroker-Sentry mit unnötigen Fehlermeldungen zubombt.wisst ihr, wie man an dieser Stelle der Ausführung mehr debug infos herausholen kann?
Leider steht im iobroker log nix dazu. vscode erhält halt irgendeinen anderen exit code und sagt dann failed aber ohne mehr Informationen auszugeben. -
@OliverIO Dummerweise sagt
iob plugin disable sentrywohl nicht mehr, oder? Ich nehme an, der schlägt fehl - eventuell weil etwas noch nicht bereit ist? Keine Ahnung... -
@UncleSam @AlCalzone
Ich habe mal dem buanet einen Issue geschrieben, das er hier mal reinschauen soll. -
@OliverIO sagte in VisualStudio Code und Devcontainer:
@UncleSam @AlCalzone
Ich habe mal dem buanet einen Issue geschrieben, das er hier mal reinschauen soll.Da bin ich.
Hab jetzt allerdings nicht alles hier gelesen, und da ich auch keine Ahnung von Adapterentwicklung habe wird es sicher nicht einfach für mich mich hier rein zu denken....
Aber was Docker angeht bin ich eigentlich soweit auf dem Stand. Vielleicht kannst du kurz zusammen fassen was das Problem ist und wo ich mich rein lesen kann...MfG,
André -
@andre
vielen Dank für deine zeit und dass du so kurzfristig hier mit reinschaust.Das Problem ist noch bevor es mit der Adapterentwicklung losgeht.
Über das folgende docker-compose file wird der docker container vorbereitet, so das dieser im Rahmen der Entwicklung eingesetzt werden kann aufgebaut.
Das workspaceverzeichnis lebt einmal auf dem client-computer und in einer volume und wird von vscode auch immer synchroisiert. für vscode gibt es eine separate Konfigurationsdatei in der @AlCalzone noch ein paar Befehle eingefügt hat, die eigentlich erst ausgeführt werden, wenn alle container gebaut wurden.
Bei manchen (bspw bei mir) gibt es damit aber Probleme.
Zustand nach der Erstellung des containers ist, iobroker läuft, aber der adminadapter wird nicht gestartet.
Meine Recherchen haben ergeben, das die Umbenennung des hostnamens, welche in einem Skript in deinem buanet container erledigt wird, wohl nicht sauber durchläuft. Dadurch erkennt iobroker keine gültigen instanzen für diesen host und startet diese dann auch nicht.
leider habe ich keine ahnung, wie ich mehr debug-informationen bei der container Erstellung erhalte um rauszufinden, wo das Problem genau sein könnte.Wenn diese Extrabefehle aus der Config von vscode nicht ausgeführt werden, dann startet der Container einwandfrei.
Hier mal die eine Konfigurationszeile aus der vscode config (devcontainer genannt), mit den Befehlen
// When creating the container, delete unnecessary adapters, disable error reporting, set the license as confirmed, and install/update this adapter "postCreateCommand": "iob del discovery && iob plugin disable sentry && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url \"$(pwd)/$NPM_PACK\" --debug && rm \"$NPM_PACK\""Noch eine Zusatzinformation:
Wendet man diese Befehle direkt in einer shell im container an, dann laufen die ordnungsgemäß durch. im speziellen erzeugt "iob plugin disable sentry" aber in dem Kontext in dem dieser von vscode nach der container erstellung ausgeführt wird aber einen nicht näher spezifizierten Fehler (vs code bzw docker exec meldet einfach nur failed)Auch wenn es evtl schon ein bisschen viel Information ist hier noch das vscode logfile für die container Erstellung, da stehen alle abgesetzten Befehle drin
-
@OliverIO Ok, soweit habe ich das glaub ich verstanden.
Fragen:
- Wer führt die Befehle aus der vsconfig aus, bzw. wie werden diese getriggert?
- Wie sieht das Logfile des ioBroker Containers aus? Für jeden Schritt den das Startup Script macht gibt es dort ja eine entsprechende Ausgabe
Wenn es es sich beim postCreateCommand um eine Vorbereitung des iob Containers handelt, hast du mal versucht die Kommandos in ein user defined startup script zu packen und die "Vorbereitung" vom startup script des containers erledigen zu lassen?
MfG,
André -
@andre sagte in VisualStudio Code und Devcontainer:
postCreateCommand
Führt VSCode bzw. die Container-Erweiterung einmalig beim Erstellen (bzw. Rebuild) des Containers aus. Die von dir genannten startup scripts sollten das aber nahtlos ersetzen können.
-
@AlCalzone @andre
Nach ein bisschen aufteilen der Befehle scheint der iobroker erst einmal zu laufen.
Allerdings sind Änderungen an der Datei index_m.html nicht in iobroker sichtbar. Auch nicht nach mehrmaligem upload über das iobroker ui
Meine Dateien sehen erst einmal so aus:docker-compose.yml
devcontainer.json
userscript_firststart.sh
vscode log
Bin mal gespannt, ob ich der einzige bleibe, der diese Probleme hat und an was es dann am Ende liegt.
-
@OliverIO Danke für die Zusammenfassung. Ich habe mir das in https://github.com/ioBroker/create-adapter/issues/637 mal vermerkt.
@OliverIO sagte in VisualStudio Code und Devcontainer:
Allerdings sind Änderungen an der Datei index_m.html nicht in iobroker sichtbar.
Wie sieht denn deine nginx.conf aus? Kann sein, dass der hot-reload derzeit nur bei React funktioniert - könnte man aber anpassen.
-
@AlCalzone sagte in VisualStudio Code und Devcontainer:
Kann sein, dass der hot-reload derzeit nur bei React funktioniert - könnte man aber anpassen.
Das ist so, allerdings sollte F5 im Browser definitiv die Seite neu laden.
@OliverIO sagte in VisualStudio Code und Devcontainer:
Auch nicht nach mehrmaligem upload über das iobroker ui
Das hat auch keine Auswirkung: die Dateien werden von nginx direkt vom workspace Folder zur Verfügung gestellt.
-
@UncleSam sagte in VisualStudio Code und Devcontainer:
nginx direkt vom workspace Folder zur Verfügung gestellt.
Hast Recht, ich dachte wir haben das nur bei React aktiv - ist aber immer so:
https://github.com/ioBroker/create-adapter/blob/ccd92f13d6a77a062757bf5393f8e2ed7c71fa2c/templates/_devcontainer/nginx/nginx.conf.ts#L34-L36 -
@AlCalzone @UncleSam
Könnt ihr mal bitte testen, ob bei euch im Container die watch-Geschichten funktionieren (parcel, gulp oder babel)
Bei mir werden im /workspace Ordner keine Ereignisse ausgelöst, in anderen schon.
Das macht das automatische rebuild von react bspw etwas schwierig.
Habe dazu auch issues für docker for windows gefunden. -
@OliverIO Ja, geht nicht. Respektive nur wenn du deine Dateien im WSL hast und nicht unter Windows:
https://www.docker.com/blog/docker-desktop-wsl-2-best-practices/
Und vor allem: https://docs.docker.com/docker-for-windows/wsl/#best-practicesDie andere Lösung haben wir im create-adaper eingebaut: du kannst Chokidar sagen, er solle das Dateisystem pollen:
https://github.com/ioBroker/create-adapter/blob/ccd92f13d6a77a062757bf5393f8e2ed7c71fa2c/templates/_devcontainer/docker-compose.yml.ts#L42 -
@UncleSam
Super danke -
Möchte auch mein Feedback geben:
Ich habe vor ein paar Tagen via Adapter-Creator einen Adapter zum Testen erstellt (Typescript, DevContainer, React-GUI). Ich hatte auch das Bad-Gateway-Problem. Ich hatte etwas rumprobiert - ohne Erfolg. Am nächsten Tag funktionierte es dann aber plötzlich! "postCreateCommand" war aber aktiv.
Mit weiterem Rumprobieren bin ich schrittweise weitergekommen, aber teils auch wieder angestanden, sodass ich gestern beschloss, nochmals von vorne anzufangen.
Allerdings habe ich es mit dem neu generierten Container nicht mehr geschafft, das Bad-Gateway-Problem loszuwerden. Die Instanzen werden nicht gestartet. Auch wenn ich postCreateCommand auskommentiere.
Jetzt habe ich zwei Container, wobei ich beim einen auf ioBroker zugreifen kann und beim zweiten bekomme ich den Bad Gateway Fehler. Ich hab schon Folder-Vergleiche gemacht, aber ich werde nicht schlau draus. Gibt es da irgendwas auf das ich speziell schauen könnte?
Mittlerweile habe ich es aber geschafft, dass der erste funktioniert.
Hier ein paar Punkte, über die ich gestolpert bin:
- Wenn ich CHOKIDAR_USEPOLLING=1 gesetzt lasse, dann geht der Parcel-Container auf 200% CPU (top in der Console) bzw. Vmmem meines 4 Cores/8 Threads-Systems auf 50%. (Ist allerdings schon ein ziemlich alter i7).
- Ich hatte überlesen, dass man eine Instanz des Adapters erstellen muss. Der Adapter taucht ja in der Adapterliste auf. Als ich noch keine Instanz erstellt hatte, brach er beim Debuggen immer mit Exit Code 2 (INVALID_ADAPTER_CONFIG) ab.
- Die installierte Instanz sollte aber gestoppt werden. Als sie lief, hatte ich den Eindruck, dass zwar beim Debuggen in VSCode mein bereits geänderter Adapter lief (anhand von console.log), aber im ioBroker-Log nur die Log-Einträge des ursprünglich generierten Adapters zu finden waren.
- Zum direkten Debuggen von Typescript muss man sich an die launch.json halten, die UncleSam am Anfang dieses Threads gepostet hat. Hier wird die main.ts als "program" gesetzt. Allerdings musste ich in package.json "sourceMap" auf true stellen. Hatte es anfangs nur in der launch.json gesetzt - das hat bei mir nicht funktioniert. Die anderen hier geposteten launch.json-Beispiele beziehen sich auf JavaScript.
- Beim Ausführen von create-adapter traten am Ende Fehler auf:
Ich nehme mal an, die kann man ignorieren. Ich hab die Befehle dann manuell ausgeführt. Also build:parcel bzw.
npm run build:ts && npm run build:parcel. Dabei hat sich gezeigt, dass @sentry/browser fehlt. (vermutlich dieses Problem: https://github.com/ioBroker/create-adapter/issues/657). Hab es hinzugefügt, dann laufen auch diese Builds durch. -
@noox Danke für das Feedback.
@noox sagte in VisualStudio Code und Devcontainer:
Beim Ausführen von create-adapter traten am Ende Fehler auf
Wenn ich das richtig interpretiere, ist das ein bekannter Fehler in adapter-react, dr bekannt ist.
-
@UncleSam said in VisualStudio Code und Devcontainer:
Wenn ich das richtig interpretiere, ist das ein bekannter Fehler in adapter-react, dr bekannt ist.
Ja, denke ich auch. Ich dachte ich vermerke es hier, weil womöglich ein Neuling wie ich bei solchen Problemen länger sucht oder herumprobiert.
-
Ich wollte mal, nachdem einige Zeit vergangen ist mich nochmal an den devcontainer wagen.
Diesmal habe ich es auf einem Remote-Rechner versucht mit folgendem Ergebnis. Die Logfiles sind etwas groß, hab mich aber dazu entschlossen, die komplett hochzuladen. evtl seht ihr ja noch etwas was ich übersehen habe.Ziel Entwicklung in einem devcontainer auf einem remote-server
Auf dem remote server ist Debian GNU/Linux 10 (buster) installiert
In einem Verzeichnis wurde mittels dem Adapter creator der folgende adapter angelegt.
Darüber hinaus gab es keine weiteren Anpassungen an irgendeiner Datei
Nach der Verbindung mit vs code zum server wurde das Verzeichnis zum Adapter geöffnet
vs code hat automatisch erkannt, das hier ein devcontainer vorliegt. dieser wurde geöffnet- Durchlauf
Log des Erstellungsprozesses
Log des Sub terminal mit dem Fehler zu postCreateCommand, der zum ende des ersten Durchlaufs geführt hat
Nach Abbruch des 1.Durchlaufs habe ich vs code geschlossen und wieder erneut geöffnet
Protokoll des 2.DurchlaufsDas Terminal hat sich nicht mehr geschlossen und für die letzten Befehle scheint es kein Exit Code mehr zu geben.
Ob das richtig oder falsch ist kann ich nicht beurteilen.Als nächstes habe ich unter der IP-Adresse des Remote-Rechners versucht iobroker mit IP-Adresse:8082 aufzurufen.
Grundsätzlich lädt es auch etwas was nach einem Startbildschirm mit dem iobroker-Logo in der Mitte aussieht.
Allerdings geht es nicht mehr weiter.
Im Browserlog ist folgender Fehler zu finden, der sich alle 5 Sekunden wiederholt - Durchlauf
-
@oliverio
nachdem ich das weiter untersucht habe, habe ich den fehler gefunden.
die nachrichten zwischen client und server werden über websockets übermittelt.
die anfragen zu websockets müssen allerdings speziell weitergeleitet werden.
dazu ist in der nginx configuration eine separate location angegeben, die auf den match /socket.io/ horcht.
problem ist, das die websockets anfragen nicht mit dieser url übermittelt werden.durch folgende Anpassung werden nun die websockets ebenfalls korrekt vermittelt.
Da leider kein direkter Match auf /?sid möglich war, hier der Umweg über die auswertung der Argumente.location / { error_page 418 = @websocket; proxy_redirect off; proxy_pass http://iobroker:8081; if ( $args ~ "sid=" ) { return 418; } } location @websocket { proxy_pass http://iobroker:8081; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_read_timeout 86400; proxy_send_timeout 86400; } -
Hallo,
ich starte ein Projekt das mit einem aktuellen Template mit Dockerunterstützung gebaut wurde, z.B.
https://github.com/UncleSamSwiss/ioBroker.loxone
oder auch andere.
Docker Desktop ist installiert. Dann mit Visual Studio Reopen in Container gewählt.
Nach dem Download des Images und Start des Containerts kommt immer diese Meldung:[80537 ms] Start: Run in container: /bin/sh -c iob del discovery && iob plugin disable sentry && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url "$(pwd)/$NPM_PACK" --debug && rm "$NPM_PACK" Delete adapter "discovery" removed 42 packages in 777ms 26 packages are looking for funding run `npm fund` for details Objects database error: connect ECONNREFUSED 127.0.0.1:9001 Objects database error: connect ECONNREFUSED 127.0.0.1:9001 Objects database error: connect ECONNREFUSED 127.0.0.1:9001 Objects database error: connect ECONNREFUSED 127.0.0.1:9001 The host "iobroker-loxone" does not exist! [129608 ms] postCreateCommand failed with exit code 30. Skipping any further user-provided commands. Done. Press any key to close the terminal.und dann noch:
[129608 ms] Error: Command failed: /bin/sh -c iob del discovery && iob plugin disable sentry && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url "$(pwd)/$NPM_PACK" --debug && rm "$NPM_PACK" [129608 ms] at RL (c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js:1690:137) [129608 ms] at process.processTicksAndRejections (node:internal/process/task_queues:96:5) [129609 ms] at async Promise.all (index 0) [129610 ms] at async qg (c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js:1682:3580) [129610 ms] at async $g (c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js:1682:2837) [129611 ms] at async rue (c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js:2013:27124) [129611 ms] at async tue (c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js:2013:24813) [129631 ms] Exit code 1 [129632 ms] Command failed: C:\Users\user\AppData\Local\Programs\Microsoft VS Code\Code.exe --ms-enable-electron-run-as-node c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-containers-0.262.3\dist\spec-node\devContainersSpecCLI.js run-user-commands --user-data-folder c:\Users\user\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --workspace-folder c:\Users\user\Documents\ioBroker.loxone --id-label devcontainer.local_folder=c:\Users\user\Documents\ioBroker.loxone --container-id 5bfcd24f499c876e3a959d535b25abf6132f6f2bc1f3ead064d5e2a992cd7e84 --log-level debug --log-format json --config c:\Users\user\Documents\ioBroker.loxone\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --skip-non-blocking-commands false --prebuild false --stop-for-personalization true --remote-env SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-bc7676f9975cc0230a214853edad6797a4528700.sock --remote-env REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-bc7676f9975cc0230a214853edad6797a4528700.sock --remote-env REMOTE_CONTAINERS=true --mount-workspace-git-root true --terminal-columns 186 --terminal-rows 18Der Webserver ist zwar irgedwie erreichbar auf http://127.0.0.1:8081/ es kommt aber nur das Startlogo. Könnt ihr mir sagen was bei mir falsch läuft?
