Home Assistant Pull Requests Tracker

Development
1

Weeks ago there was some discussion in #devs about the difficulty of finding developers to assist debugging platforms. Basically if you fixed/improved on a platform you would need to wait for the release to get feedback from actual users.

At the time I though about creating a platform to track users hardware, so that the developer could pick someone up for a test run. But from a privacy point of view, its a bad idea.

I think it would be best for developers to become aware that there are new pull requests (PR) related to their hardware, and push their awareness to new PR (voluntary conscription).

I would therefore like your feedback on a possible new component, specially target at this scenario (can be extended to issue tracking also). Is it useful ? Suggestions and Improvements are appreciated.

The idea is that similar to updater component, the home-assistant repo is monitored and persistent notifications are triggered for PR relating to the current configuration.

2

I like this idea, but IMO…

The updater component needs rewriting badly, I believe at this moment it requires somebody to manually change something somewhere to trigger the notification. I stopped using it because it always notified way too late, and replaced it with a sensor that tracks pypi.

Also AFAIK, the updater component does not take into account the new ‘banded’ releases.

So…

(if you felt like it, and this is just a suggestion :slight_smile: )

It would be better to make a new updater component that tracks pypi natively, tracks the stable release but can be overridden to track beta or dev, and also incorporates what you’re doing here.

updater: #new version that tracks pypi
 include_used_components: true #default false for privacy
 branch: rc #default stable for reliability 
 config_monitor: true #your suggestion is this option, default false for privacy

To clarify, I really really really do like this idea, but think it should be incorporated into an improved updater component as an opt-in personally.

3

Thanks for the feedback, but this is completely parallel to the updater.

Furthermore you could use this feature without the updater and vice-versa.

Your main hurdle (time it takes to update) is actually a feature :smiley: to avoid hammering the updater service.

4

Ha, if you say so :stuck_out_tongue_winking_eye:

cough

Anyway, yes, I love the idea of the feature, is it ready for testing in its current form? If so I’ll integrate it as soon as I get chance.

5

I’m trying to learn a bit more about how these things work, so whilst I’m looking at your code, should this not be vol.Required?

CONFIG_SCHEMA = vol.Schema({DOMAIN: {
    vol.Optional(CONF_GITHUB_PERSONAL_TOKEN, default=None): cv.string,
}}, extra=vol.ALLOW_EXTRA)

Or if not, how come?

… And you might be able to help me with a few other bits later too :wink::wink:

6

You can use github’s API to do check HA pull requests without being logged.

the drawback is the limited number of API calls.

7

OK cool, shall I chuck it in and test it out for you?

8

Sure, go ahead

1 Like