Enabled dev-mode functionality to setup a "custom repository to load from"

[tmack8001]

The intention of this dev-mode is to allow developers (both baronbrew and contributing developers) to setup a github branch as the source for "Update App (Flow)" button in the TiltPi UI. In doing so I decided it would also be helpful to have the latest official update documented in the UI so a user would know if hitting "Update App (Flow)" would actually load any changes.

NOTE I'm relying on Github Releases to determine this... which isn't currently setup in baronbrew/TILTpi, but I have an example changelog in my fork, https://github.com/tmack8001/TILTpi/releases/tag/v.2.5

Here is a preview of what that would look like for users.

no update

new release (either from developer's custom release or the official release track)

[tmack8001]

Within this I also added 2 debug nodes in helping to diagnosis another issue I ran into about the Cloud Provider logging. These mostly just log out the payload and response from the cloud provider. They are disabled by default, but can easily be enabled. Later I want to expose the cloud provider's error into the UI for the end user so that there isn't a need to go into the node-RED interface to determine what is broken with publishing.

[noahbaron]

Changes look good. Thanks for putting that together. Contributions and testing will be much more manageable now. I added the v.2.5 release on the baronbrew account and verified the version checker is working, great idea, didn't really know about Github release functionality. My guess is I'll need to update v.2.5 to include these changes in the release since I haven't merged the changes yet. Will do this today. Regards,

…

On Fri, Apr 3, 2020 at 8:12 AM Trevor Mack ***@***.***> wrote: Within this I also added 2 debug nodes in helping to diagnosis another issue I ran into about the Cloud Provider logging. These mostly just log out the payload and response from the cloud provider. They are disabled by default, but can easily be enabled. Later I want to expose the cloud provider's error into the UI for the end user so that there isn't a need to go into the node-RED interface to determine what is broken with publishing. [image: image] <https://user-images.githubusercontent.com/2158627/78376100-d3157180-759b-11ea-858e-dda066ef3ce8.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3FBJBZJGL37U472N6P4DRKX4FTANCNFSM4L4D7RUA> .

[tmack8001]

My guess is I'll need to update v.2.5 to include these
changes in the release since I haven't merged the changes yet.

I'd just leave v.2.5 where it is and add this into a v.2.6 release entry within Github's UI. Then have that track the merged commit of this PR on top of the existing v.2.5 on the Aiolblescan branch. We shouldn't get in the practice of modifying release targets and instead leave releases as unmodifiable elements of the repo.

Ideally the Node-RED interface should pull the source of the release's tag instead of being hardcoded to the branch we are using today of Aiolblescan. To check out the release API checkout, https://api.github.com/repos/baronbrew/tiltpi/releases/latest. However, please be aware without authentication there is rate limiting enabled to 60 requests an hour (thus the 1/5min limiter I put in place).

[noahbaron]

Sounds good to me. Not sure if I did this exactly as you suggested (still learning github), but I added a v.2.6 release with a description of the new features on the github release page ui. The new feature description I realized needs to be manually updated in the flow too, so it still shows the v.2.5 new features, will keep this in mind next time.
I agree it should pull based on the releases tag. Will take a closer look at the api.

[tmack8001]

@noahbaron I could look at building a small bash script that would be able to be used to generate and populate the "inner flow" changelog, tag and push to github for you.

Then the only manual thing to do would be to create the release in github (which could in theory also be automated in this script using an API token).

[tmack8001]

nice, love it! Yes you did the release in github right though might want to upgrade the tag destination to a5cbb0777fbc013eff21daef7e3f75196127bbf4 which fixes some of the merge conflicts that happened.

[tmack8001]

I also want to explore having a "download and compare" periodic task (once a day / once an hour) which will look at the loaded flow.json and compare it with the remote source for the same version to see if there is a change. This could then be exposed in the UI on this same admin / version description experience to signal that the tiltpi effective flow has been modified by the end user.

[noahbaron]

Sounds like a great idea.

…

On Mon, Apr 6, 2020 at 8:32 AM Trevor Mack ***@***.***> wrote: I also want to explore having a "download and compare" periodic task (once a day / once an hour) which will look at the loaded flow.json and compare it with the remote source for the same version to see if there is a change. This could then be exposed in the UI on this same admin / version description experience to signal that the tiltpi effective flow has been modified by the end user. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3FBLZSTBWQSV4ASHNI3DRLHYZ5ANCNFSM4L4D7RUA> .