Closed TaplistIOTeam closed 3 years ago
Ugh. You're going to make me build actual Github integration for TiltBridge's firmware list, aren't you?
😢
Hahah. That thought did cross my mind! Hit up releases api client side from the firmware page... :)
Hahah. That thought did cross my mind! Hit up releases api client side from the firmware page... :)
Interestingly enough, my project earlier today was building basically this exact code for a different project. I will admit I was thinking of going down this route...
Project for later this year. ;)
BTW - I'm holding off on merging this until probably ~Sunday due to the way that BrewFlasher integrates with everything. Although I don't expect that this will cause any issues, I also don't want to get excited about having automatically updating releases and stay up late working on the same.
Haha, no problem! Run with it however + whenever you see fit; whipped up out of pure curiosity.
@lbussy I notice you are still maintaining firmware manually in the cloud branch. If you're interested, you could merge this and start getting some mileage on it. Something like the following:
cloud
branch, or wherever active development is happening, start using tags to trigger builds. eg:
v2.0.0-cloud-pre1
No rush, just a small idea to start getting some cycles + keep this from bit rotting.
Man, I have the memory of a goldfish. Merging.
This change will:
latest-{master,devel}
every time a PR is merged to one of those branches; andv*
is pushedThe former means "bleeding edge" auto-built binaries should always be available, e.g. to interested testers. The latter I hope removes a chore associated with cutting new releases: just push the tag & let the action handle the rest.
Because of the conditional nature of those triggers, we won't be able to observe either of these things in this PR, unless it is merged. So I did a fake PR & merge in our fork: here's the PR, the action that ran once merged, and the
latest-devel
release the action created.