NEWS
VisualStudio Code und Devcontainer
-
@OliverIO sagte in VisualStudio Code und Devcontainer:
Die korrupten Dateien sind in welchem Verzeichnis entstanden? Soll ich da nochmal speziell schauen?
Das ganze
/opt/iobroker
wird ja gemountet, also irgendwas dort drin (wäre ja auch bei dir so). Es war ein installiertes Node Module. -
@UncleSam
dann ist im Windows-Fall nichts korrupt. Ohne postCreateCommand läuft alles super.
Mit postCreateCommand erst nachdem man die hosts wie beschrieben wieder umbenannt hat.
Mir dünkt, das die Befehle in postCreateCommand gar nicht ausgeführt wird. Muss aber nochmal genauer schauen. -
@AlCalzone @UncleSam
Hi,ich hab hier noch ein wenig rum experimentiert und konnte es ein wenig eingrenzen.
Problem 1) sobald der Befehl "iob plugin disable sentry" enthalten ist, erscheint im Log von vs code bei der Erstellung des Containers immer ein postCreateCommand failed[2020-11-20T12:38:42.946Z] [PID 11220] [8148 ms] Start: Run: docker exec -i -u root -e SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-94fa740e69f0e0f5f0af463318e0645c8f73d97c.sock -e REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-94fa740e69f0e0f5f0af463318e0645c8f73d97c.sock -e REMOTE_CONTAINERS=true -w /workspace 52441b62fc5a811d95518668a85e15327e3c1ee79f3763a685d25d0fd6351011 /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" [2020-11-20T12:38:45.560Z] [PID 11220] [10762 ms] Delete adapter "discovery" [2020-11-20T12:38:45.563Z] [PID 11220] [10765 ms] npm uninstall iobroker.discovery --error --prefix "/opt/iobroker" (System call) [2020-11-20T12:38:48.790Z] [PID 11220] [13992 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) [2020-11-20T12:38:48.797Z] [PID 11220] [13999 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) [2020-11-20T12:38:48.797Z] [PID 11220] [13999 ms] [2020-11-20T12:38:53.360Z] [PID 11220] [18562 ms] 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\"" failed.
lass ich es weg, dann läuft zumindes die postCreateCommand komplett durch
[8093 ms] Start: Run: docker exec -i -u root -e SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-f5e8539333a46dc4ea70ee13c568241fac389e86.sock -e REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-f5e8539333a46dc4ea70ee13c568241fac389e86.sock -e REMOTE_CONTAINERS=true -w /workspace fc7f0285e005382bea59f9366038fa839488249323ee8d8291a1e95f49d3125b /bin/sh -c iob del discovery && iob object set system.config common.licenseConfirmed=true && NPM_PACK=$(npm pack) && iob url "$(pwd)/$NPM_PACK" --debug && rm "$NPM_PACK" [10698 ms] Delete adapter "discovery" [10702 ms] npm uninstall iobroker.discovery --error --prefix "/opt/iobroker" (System call) [14117 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fsevents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) [14125 ms] npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) [14126 ms] [17551 ms] The object "system.config" was updated successfully. [21506 ms] install /workspace/iobroker.luxtronik2-0.0.2.tgz [21644 ms] NPM version: 6.14.8 [21645 ms] npm install /workspace/iobroker.luxtronik2-0.0.2.tgz --loglevel error --prefix "/opt/iobroker" (System call) [24519 ms] + iobroker.luxtronik2@0.0.2 added 7 packages from 80 contributors in 2.529s [24659 ms] 15 packages are looking for funding run `npm fund` for details [24694 ms] upload [4] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/words.js words.js application/javascript [24750 ms] upload [3] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/style.css style.css text/css [24804 ms] upload [2] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/luxtronik2.png luxtronik2.png image/png [24859 ms] upload [1] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/index_m.html index_m.html text/html [24912 ms] upload [0] luxtronik2.admin /opt/iobroker/node_modules/iobroker.luxtronik2/admin/admin.d.ts admin.d.ts video/mp2t
Aber in beiden Fällen läuft iobroker zwar auf dem Server, aber admin wird nicht gestartet, daher kein Browserzugriff
Problem 2: (denke ich)
Wenn man in beiden Logs den Befehl docker exec anschaut, dann bemerkt man, das zur Ausführung ein temporärer Container gewählt wird und nicht der schon umbenannte.
Das würde zumindest das erklären, warum es keine Probleme gibt, wenn kein postCreateCommand angegeben wurde. -
@OliverIO sagte in VisualStudio Code und Devcontainer:
das zur Ausführung ein temporärer Container gewählt wird
Woher siehst du das? Kannst du mal in der Liste der Befehle noch
hostname &&
hinzufügen? So gibt er den Hostnamen des aktuell laufenden Containers aus. -
@OliverIO sagte in VisualStudio Code und Devcontainer:
Wenn man in beiden Logs den Befehl docker exec anschaut, dann bemerkt man, das zur Ausführung ein temporärer Container gewählt wird
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. -
@UncleSam
ok, ne, hostname gibt den korrekten hostname aus.
Problem muss beim umbenennen des hostnamens liegen.
Was mich wundert ist halt die Rückkopplung von postCreateCommand dazu.
An der Stelle ist der Container doch schon fertig gebaut und der hostname umbenannt.
Aber mit postCreateCommand klappts nicht
ohne funktioniert es einwandfrei. -
@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 sentry
wohl 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