Commit hash always 'unknown'

[CodeFinder2]

I am using the latest zigbee2mqtt with this HassIO addon and observed that it always publishes something like

AM MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.3.0","commit":"unknown","coordinator_firmware":20190109,"log_level":"debug","permit_join":false}'

I am referring to the "commit":"unknown" here. Should be just a minor issue. Or do I miss something?

[paskyecijano]

I have the same error

[hawaltie]

I also have the same 'error'

[danielwelch]

Looking at merging this in for version 1.5.0

[ciotlosm]

It still shows unknown in 1.6.0 stable. It does show the commit in the edge version.

  zigbee2mqtt:info 10/20/2019, 9:44:05 AM Logging to directory: '/share/zigbee2mqtt/log/2019-10-20.09-44-02'
  zigbee2mqtt:info 10/20/2019, 9:44:05 AM Starting zigbee2mqtt version 1.6.0 (commit #unknown)

  zigbee2mqtt:info 10/20/2019, 9:44:12 AM MQTT publish: topic 'zigbee2mqtt/bridge/state', payload 'online'
  zigbee2mqtt:info 10/20/2019, 9:44:12 AM MQTT publish: topic 'zigbee2mqtt/bridge/config', payload '{"version":"1.6.0","commit":"unknown","coordinator":20190608,"log_level":"info","permit_join":false}'

[danielwelch]

@ciotlosm yeah, that's expected. Here's the relevant bit in the edge version Dockerfile

hassio-zigbee2mqtt/zigbee2mqtt-edge/Dockerfile

Line 25 in 0f90461

RUN jq -n '{"hash": env.COMMIT}' > ./.hash.json

I didn't include this in stable version because it's using a known release of zigbee2mqtt by definition, which I figured would be the most relevant info. With that said, that release obviously is tied to a commit, and I guess it couldn't hurt to provide the hash as well, even if it is kind of redundant.

[CodeFinder2]

@ciotlosm yeah, that's expected. Here's the relevant bit in the edge version Dockerfile

hassio-zigbee2mqtt/zigbee2mqtt-edge/Dockerfile

Line 25 in 0f90461

RUN jq -n '{"hash": env.COMMIT}' > ./.hash.json

I didn't include this in stable version because it's using a known release of zigbee2mqtt by definition, which I figured would be the most relevant info. With that said, that release obviously is tied to a commit, and I guess it couldn't hurt to provide the hash as well, even if it is kind of redundant.

So, will it finally be included? (I think having it printed is useful, although redundant. Alternatively, you should remove the commit hash completely for releases because this now looks a bit 'incomplete'. 🙈 Nonetheless, I would appreciate seeing the version number and commit hash.)

It's still not in v1.7.1 v1.8.0 v1.9.0 v1.10.0:

zigbee2mqtt:info 2020-02-19 13:01:09: Starting zigbee2mqtt version 1.10.0 (commit #unknown)

[ciotlosm]

@danielwelch should we close this based on #388 ?

[danielwelch]

If someone can confirm it works :)

[CodeFinder2]

Sorry, not working for me:

info  2020-09-18 16:35:19: Logging to console and directory: '/share/zigbee2mqtt/log/2020-09-18.16-35-19' filename: log.txt
debug 2020-09-18 16:35:19: Removing old log directory '/share/zigbee2mqtt/log/2020-08-15.16-26-49'
debug 2020-09-18 16:35:20: Loaded state from file /share/zigbee2mqtt/state.json
info  2020-09-18 16:35:20: Starting Zigbee2MQTT version 1.14.4 (commit #unknown)
info  2020-09-18 16:35:20: Starting zigbee-herdsman...
debug 2020-09-18 16:35:20: Using zigbee-herdsman with settings: 

Addon version: 1.14.4.1

[danielwelch]

So you're not on edge? This is only supposed to work on edge as of now.

[CodeFinder2]

Ah sry, yes didn't use edge 🙈

[ciotlosm]

Finally got to install a dev instance with a separate CC2531. Seems the commit hash is still not working for edge.

Zigbee2MQTT:info  2020-09-19 07:41:47: Starting Zigbee2MQTT version 1.14.4-dev (commit #unknown)

Later edit:
After thinking about it and creating an issue on z2m as well, I came to the conclusion that we should have a .hash.json also for stable, populated with the actual version, this way the message would no longer look like a problem for users.

From (commit #unknown) to (commit #1.14.4) that would also be reflected in bridge mqtt message.

[ciotlosm]

@danielwelch apparently there is an error when running the pipeline.

[ciotlosm]

Fixed in 1.14.4.2