Comments (25)
I think we should modify this to use Koenkk/zigbee2mqtt#96 as dependency. Everything else about the addon is in right working condition.
from hassio-zigbee2mqtt.
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
from hassio-zigbee2mqtt.
@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:
- on each build and docker push, if the corresponding git commit is tagged, the docker image will be tagged
latest
and with the git tag version number. - however, if the commit is untagged (as would be the case for all builds triggered by updates to
zigbee2mqtt
), there is no version tag assigned, and thetest
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?
from hassio-zigbee2mqtt.
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
from hassio-zigbee2mqtt.
Not a bad idea, especially since without versioned releases we're really relying on the stability of the "bleeding edge" of zigbee2mqtt
from hassio-zigbee2mqtt.
from hassio-zigbee2mqtt.
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
from hassio-zigbee2mqtt.
@danielwelch I think there could be another approach:
- Keep 0.1 as stable version
- Create a secondary repo that uses "test" image for people that want to use "unstable" - or some other alternative for this
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.
from hassio-zigbee2mqtt.
@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.
from hassio-zigbee2mqtt.
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.
from hassio-zigbee2mqtt.
So updating https://github.com/danielwelch/hassio-zigbee2mqtt/blob/master/zigbee2mqtt/config.json#L3 everytime with the latest zigbee2mqtt commit hash would be ok?
from hassio-zigbee2mqtt.
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.
from hassio-zigbee2mqtt.
@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.
from hassio-zigbee2mqtt.
Great! I'm on telegram: @Koenkk
from hassio-zigbee2mqtt.
For whatever reason, I can't find that username on the global search. I'm on telegram @dwelch, maybe you'll have more luck
from hassio-zigbee2mqtt.
Is there any way for users to do version pinning to a specific zigbee2mqtt version if some users desire it?
from hassio-zigbee2mqtt.
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?
from hassio-zigbee2mqtt.
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 :-)
from hassio-zigbee2mqtt.
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)?
from hassio-zigbee2mqtt.
@danielwelch totally agree
from hassio-zigbee2mqtt.
@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).
from hassio-zigbee2mqtt.
@danielwelch I was wondering if that possible. I think it's a really good way to do it. 👍
from hassio-zigbee2mqtt.
Zigbee2mqtt just released their first versions release a day ago.
from hassio-zigbee2mqtt.
Will this also be released? Any ETA on when?
from hassio-zigbee2mqtt.
See #36
from hassio-zigbee2mqtt.
Related Issues (20)
- Feature - unsupported devices wizard/report tool HOT 4
- Can't remove deprecated options from configuration HOT 10
- OSRAM AC03648 randomly loosing connection
- Switching from Z-Stack 3.0.x to 1.2 returns error "Backup is only supported for Z-Stack 3" and zigbee2mqtt doesn't start HOT 2
- [supervisor.addons.validate] Add-on config 'auto_uart' is deprecated, use 'uart' HOT 22
- Syntax error when adding new device HOT 2
- Socat unable to create Serial Device in /dev HOT 4
- Addon will not start with shae.sh RPi4 HASS HOT 1
- friendly_name shoud atleast be 1 char long HOT 7
- Ignore serial: section in configuration.yaml HOT 4
- Zigbee2MQTT:error HOT 3
- Template variable warning: 'dict object' has no attribute 'operation_mode'
- Archive this repository HOT 4
- 502 Bad Gateway HOT 2
- 502 bad gateway with zigbee CC2652R stick HOT 10
- Ikea Tradfri GU10 bulb issue TRADFRIbulbGU10WS345lm HOT 5
- 502: Bad gateway on new install with Con Bee 2 as addon to HA placed on VM HOT 5
- Sonoff Zigbee 3.0 USB Dongle Plus - is it bricked?
- ENOENT: no such file or directory, open '/config/zigbee2mqtt/secret.yaml'
- Error: unknown resource type "addons"
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hassio-zigbee2mqtt.