Closed danielwelch closed 6 years ago
I think this is very accurate. I was hoping to do pm2 yesterday, but the OPI setup delayed me. I will try today in a virtualised environment to do the pm2 setup and create a merge request for both #15 and #2
@ciotlosm So, with the changes in your latest pull request, I think we're ready for a 0.1 release.
However, the biggest problem is how we will track updates of the zigbee2mqtt
repository and rebuild/push new docker images which each update of the master
branch there. The current proposed solution in #19 is to trigger a travis build of this repo/image after each successful build of the zigbee2mqtt
travis CI. This is a good option, but does not integrate perfectly with the workflow of the add-on release cycle using the build-env tool that this repository uses:
latest
and with the git tag version number.zigbee2mqtt
), there is no version tag assigned, and the test
tag is applied.I'm not sure how the hass.io UI and add-on management system will respond in this instance, as I've only published using versioned releases. I certainly don't think it will allow for the very nice "update available" UI, and I suspect that tagged releases and the test
releases could not exist alongside each other (users would probably be "stuck" at the last tagged release and not presented with an option to "update" to the newest test
image).
My first thought: could the node script referenced by @Koenkk in #19 be modified to tag and bump the sub-version with each build?
@danielwelch I think there could be another approach:
Another option would be to allow @Koenkk to trigger a version increase / tag (so addon gets updated to 0.2, 0.3 etc.) when he thinks that the changes he has done are stable enough to get published.
Update: After reading again I think increasing minor version on each webhook trigger should be ok. We an always stop such process when we have a stable version on https://github.com/Koenkk/zigbee2mqtt starts using tagged releases.
@ciotlosm I agree that whatever we decide to do here, this should be a temporary measure until https://github.com/Koenkk/zigbee2mqtt development slows down and we start doing tagged releases.
The more I think about, the more I think we should just avoid a versioning release until https://github.com/Koenkk/zigbee2mqtt adopts one. I don't think we'd be able to use git tags, which is how the automated build-env system manages the docker tags, so we'd have to handle those separately, which would be a pain.
Would it be an idea to give me write access to your repo? In this way I can automatically add tags to to the latest commit which would then trigger a rebuild.
I’m ok with that. Note that for each new tag, you’d have up to update the corresponding version key in the add-on config.json
So updating https://github.com/danielwelch/hassio-zigbee2mqtt/blob/master/zigbee2mqtt/config.json#L3 everytime with the latest zigbee2mqtt commit hash would be ok?
That line needs to correspond to a docker tag. The build-env tool we use to build and push docker images will automatically tag docker images with version tags that match a corresponding git tag that is built in Travis. So, if a commit tagged v0.1.1 is found, the resulting docker image will be tagged “0.1.1” and the config line needs to be updated to 0.1.1 for users to be presented with an option to update.
@Koenkk I wrote a web service that, in response to push events from a github webhook, will trigger travis builds for this repository. It's deployed on heroku. If you'd like to tie into it, let me know and somehow I'll securely send you the URL and required secret.
Great! I'm on telegram: @koenkk
For whatever reason, I can't find that username on the global search. I'm on telegram @dwelch, maybe you'll have more luck
Is there any way for users to do version pinning to a specific zigbee2mqtt version if some users desire it?
In zigbee2mqtt
's current state, I suppose we could expose that as an optional config variable in the UI, and then just use git to get a specified version. What's the use case, out of curiosity?
I'm just thinking of "worst case scenario". Let's say zigbee2mqtt gets a PR merged that breaks some functionality that was not tested - like a setup with many sensors, and neither of us is around to roll it back or fix it for a few days.
As users area already starting to use the setup on the "production" systems, I guess it would be nice to have a backup emergency plan so nobody gets punished by their significant other :-)
Not a bad idea, especially since without versioned releases we're really relying on the stability of the "bleeding edge" of zigbee2mqtt
@ciotlosm see #23
I think we should modify this to use https://github.com/Koenkk/zigbee2mqtt/issues/96 as dependency. Everything else about the addon is in right working condition.
Yes, as soon as there’s a stable 0.1 release I’d say we can modify to use that and release a 0.1 ourselves. Would it be worth it to include an option to use the latest master (I’m thinking if someone wants to test/develop while using the addon)?
@danielwelch totally agree
@ciotlosm I think the nicest way to handle this dual offering, when the time comes, (stable 0.1 alongside latest master of zigbee2mqtt) may be to do something similar to what esphomeyaml is doing. Ottowinter is providing 2 add-ons, a stable version and edge
verions, both installable from the same Hass.io repository.
This way, we can customize the build process a little better (for example, the git clone depth difference would become a non-issue).
@danielwelch I was wondering if that possible. I think it's a really good way to do it. 👍
Zigbee2mqtt just released their first versions release a day ago.
Will this also be released? Any ETA on when?
Yes, this will be released soon (few days). I’d like to do a versioned release which clones zigbee2mqtt’s release, and a separate add-on (same repository) for an “edge” version that will operate similarly to how this add on has worked so far, tracking master
See #36
@ciotlosm
Seems like we're nearing a point where we can go to a first versioned release. Creating a tracking issue to that end:
[x] resolve #15
[x] resolve #2 (add pm2)
[ ] determine how to handle versioning / releases