Auto Dashboard releases

[SimonFischer04]

Fixes #118

[SimonFischer04]

This should work after we get the change in the release-script. Now working on adding the github-action.

[DutchmanNL]

This should work after we get the change in the release-script. Now working on adding the github-action.

hmm, its failing for me at my local desk

Edit: solved by 76d2b15

> iobroker.esphome@0.3.1 dashboardRelease
> ts-node scripts/dashboard-release.mts

(node:68745) ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
file:///Users/nl69zh/Developer/community/opensource/ioBroker.esphome/scripts/dashboard-release.mts:42
    const response = await fetch('https://api.github.com/repos/esphome/esphome/releases')
                     ^
ReferenceError: fetch is not defined
    at getLatestDashboardVersion (file:///Users/nl69zh/Developer/community/opensource/ioBroker.esphome/scripts/dashboard-release.mts:42:22)
    at run (file:///Users/nl69zh/Developer/community/opensource/ioBroker.esphome/scripts/dashboard-release.mts:15:50)
    at file:///Users/nl69zh/Developer/community/opensource/ioBroker.esphome/scripts/dashboard-release.mts:47:7
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:530:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12)

[DutchmanNL]

This should work after we get the change in the release-script.

what change do we need? script itself runs great nice job!

edit: Understood, related to AlCalzone/release-script#154

@Apollon77 what do you think about the PR for release script?
automation itself for this adapter is very cool from @SimonFischer04 and runs smoothly https://github.com/DrozmotiX/ioBroker.esphome/actions/runs/6883725092/job/18724832355

[SimonFischer04]

what change do we need? script itself runs great nice job!\n\nedit: Understood, related to AlCalzone/release-script#154

Yes and no. Only seems to run fine. Because when you look at the script you can see that the actuall running of the release script is commented out for now so that i can test the rest.
And you already found the release script pr..

If you arent in a rush to add this feature instantly i would for now jsut leave this as it is and wait a bit to see if upstream gets merged,

otherwiese i could temporarily add some overidde for the upstream compile changelog-plugin.

[DutchmanNL]

If you arent in a rush to add this feature instantly i would for now jsut leave this as it is and wait a bit to see if upstream gets merged,

no rush I think the current concept and PR is the right way to go. Let's wait for feedback by maintainer of release script and follow-up.
Nice journey anyway, automated update/integration and suggestion for release script covered by an automated action.... like it

[SimonFischer04]

hmm, its failing for me at my local desk\n\nEdit: solved by 76d2b15

I dont know if its necessary to introduce another dependency as node 16 is already EOL and its run only inside the github action anyway , so the end user of the adapter does not need node18.

[DutchmanNL]

hmm, its failing for me at my local desk\n\nEdit: solved by 76d2b15

I dont know if its necessary to introduce another dependency as node 16 is already EOL and its run only inside the github action anyway , so the end user of the adapter does not need node18.

Only temporary so I am also able to run it locally until my it department finally deploys 18+ 😅

[SimonFischer04]

Nice journey anyway, automated update/integration and suggestion for release script covered by an automated action.... like it

yeah I may kind of tend to "overengineer" my contributions - sometimes simple bugs led me to things that i think can be improved and then it may escalate a bit :D.
for the esphome adapter my original issue was that I updated to debian 12 => new python version => broke the dashboard. and then, well stuff happened... 😄 .
Also always trying to get fixes upstreamed as much as possible to help others (release script, actually also fixed typescript types for the client class in the nativeapi - dependency still needs to be updated here), ....

Had I similar journey a few months ago where another project had a dependency that updated which broke a template because the dependency changed from a default export to a named one.
So basically all I would have needed to do was change something like import func from 'dep' to import { func } from 'dep' in my code generated from the template. and well. ... I ended up fixing some stuff end re-writing the whole project generator to be in es-module format ...

[SimonFischer04]

Only temporary so I am also able to run it locally until my it department finally deploys 18+ 😅

Well... Good that I have root / sudo access to all of my devices 😄

maybe just leave it in your test-branch and don't fully merge it in, so the "temporary" don't get quite permanent because we forget about it. also speaking of forgetting about it, after having it running once we hopefully don't have to touch it / run locally to test again and everything just works and updates the dashboard from time to time automagically 😄

[SimonFischer04]

If you arent in a rush to add this feature instantly i would for now jsut leave this as it is and wait a bit to see if upstream gets merged,

no rush I think the current concept and PR is the right way to go. Let's wait for feedback by maintainer of release script and follow-up. Nice journey anyway, automated update/integration and suggestion for release script covered by an automated action.... like it

@DutchmanNL
Does the new implementation in the adapter directlly: #118 (comment) mean this is now useless?

[DutchmanNL]

@DutchmanNL Does the new implementation in the adapter directlly: #118 (comment) mean this is now useless?

Reviewing all PR’s it indeed feels now this is obsolete.

idea behind it and concept was great and also for me a interesting exercise to explore what’s possible with GitHub actions.

but as we were able to handle the proper version management now completely in iObroker and the Adapter configuration itself this should not be needed anymore and we can simplify the maintenance.

do you agree @SimonFischer04 ?

[SimonFischer04]

@DutchmanNL Does the new implementation in the adapter directlly: #118 (comment) mean this is now useless?

Reviewing all PR’s it indeed feels now this is obsolete.

idea behind it and concept was great and also for me a interesting exercise to explore what’s possible with GitHub actions.

but as we were able to handle the proper version management now completely in iObroker and the Adapter configuration itself this should not be needed anymore and we can simplify the maintenance.

do you agree @SimonFischer04 ?

@DutchmanNL

Not really anymore.

Still getting issues / forum messages every few weeks about conflicting python / pillow / dashboard versions.
I don;t know if it's really the best idea to leave this up to the default user ...

"New" idea:
Add a new "adapter included (recommended)" default option to the dashboard selecting, that will be handled by the automation logic in this pr (nicely fits together with newly introduced adapter tests). (combined with the (recently) instruduced auto adapter updates in admin).
Keep the other options for advanced users or debugging.

With this, we should hopefully finally rule out the recurring version mismatch issues (because it is automatically verified to work by the github action) for the average adapter user.
And still allow advanced user customization.

what do you think about that?

[DutchmanNL]

what do you think about that

I like that proposal!
So instead of always latest we predict the best which is a good idea

Still wondering if this will solve the installation/start issues sometimes but we will have to figure out

Are going to have doe that as a new PR/proposal, how would you like to proceed ?

[DutchmanNL]

PS: I updated also the auto deploy part, meaning if we implement this kind of action/automation it could also be automatically deployed to NPM under X conditions

[SimonFischer04]

Still wondering if this will solve the installation/start issues sometimes but we will have to figure out

Wont solve 100% of issues of course. But hopefully reduces (drastically).

Are going to have doe that as a new PR/proposal, how would you like to proceed ?

No promises on when, but I will do another pr with an intial proposal where we can then further discuss. Want to experiment with a few things.
Have to think a bit about how to best implement this. (f.e. dasbhoard version probably need to be stored in a config file (json?) which could be easily updataed by the action, ...)

PS: I updated also the auto deploy part, meaning if we implement this kind of action/automation it could also be automatically deployed to NPM under X conditions

How does that work / what conditions are possible?
And we need to figure out how to best create the changelog. The implementation in this PR was to dynamically add a new changelog entry during the release process, using an additional argument to the release script.
But if we now just release (from main) under X condition, then we probably need to modify the Readme file (changelog part) itself.