Re: "rolling" release artifacts on GitHub
Hi Dirk. On 10/12/23 16:17, Dirk Hohndel wrote: It also seems to be possible to create release with an indicative name without having to add it as a tag in the repository - at least when using GitHub actions to create the release: https://github.com/betaflight/betaflight-configurator/blob/07da3398426b5d6f1e0bd74d37f0e6f0cd622c39/.github/workflows/nightly.yml#L55 Interesting - everything I read in the documentation seemed to imply that this really needed a tag. How odd. This might be related to the fact that the setup in Betaflight uses a GitHub action to publish the releases into a separate '...-nightly' repository to keep them separate from the less frequent 'curated' releases - but we might want to do something similar. This is how the releases created by this look like: https://github.com/betaflight/betaflight-configurator-nightlies/releases I think that would be an excellent outcome. Would you be willing to add this to our GitHub Actions? Or would you prefer if I tried my hand on this (that won't happen for a day or two - I just came back from Japan and have a bunch of other stuff to catch up on I can certainly make a start on it. This is only a problem if you have to uninstall the app and then re-install - like when moving from the store app to a sideloaded version and encountering a new signing key because of this. If we manage to use the same signing for all of our nightly builds people will be able to upgrade between them without a uninstall / reinstall, and avoid having to re-authenticate and re-download. IIRC the builds are completely unsigned. At a minimum we'd have to create a release counter that's monotonic - it seems that the setup for betaflight-configurator already has that somewhere... I haven't looked. From what I can tell an ad-hoc key is generated whenever the dockerised build system for the APK is set up for local builds - but I haven't checked if this applies to the builds on GitHub as well, and if this key is persisted between builds. We might want to add a 'nightly key' as a GitHub secret to facilitate upgrades of the sideloaded version. But I'm not planning to do any UI changes until we have things working with Qt6 which will be a while. Maybe a 'quick win' temporary fix for this would be to add a warning about this to the 'Testing cloud credentials' prompt? Sure, that seems straight forward enough I can propose something. In summary: - we need a monotonic, automatic release counter Something like this is actually provided by GitHub, in the form of a build number counter for each action. - we should use that for all releases, regardless of platform Agreed. I think the easiest will be to create a separate GitHub action that is triggered by the completion of all of the builds, and then goes and collects all of the artifacts and turns them into a release. - we should switch to the date / counter naming scheme on all platforms Easiest to do this in the 'release action' above. - we could add a warning to the mobile builds that there may be a fairly long time where the app will look dead Am I missing anything? Would you be willing / interested to handle any (or all ) of that. I can look into most of this - if we want to move to releasing the 'nightly' builds in a separate repository then you will have to create the repository for me, and I might need help to get the access rights for the action to publish to this repository. Re naming this, I could not come up with something that is better in terms of understandability than '-nightlies' for this, even though it is a misnomer as we are considering releasing for every merge of a pull request, and not for 'one build a night' - but maybe somebody else has got a good idea. Ngā mihi Michael Keller ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: "rolling" release artifacts on GitHub
> On Dec 9, 2023, at 18:08, Michael wrote: > > > I have used (b) in the past, and gone for a concatenation of a datestring > with a counter - this results in release numbers that make it obvious how > recent they are, which is an advantage when trying to help people reporting a > problem. Yes, that is much nicer than what we do at this point. > It also seems to be possible to create release with an indicative name > without having to add it as a tag in the repository - at least when using > GitHub actions to create the release: > > > https://github.com/betaflight/betaflight-configurator/blob/07da3398426b5d6f1e0bd74d37f0e6f0cd622c39/.github/workflows/nightly.yml#L55 Interesting - everything I read in the documentation seemed to imply that this really needed a tag. How odd. > This is how the releases created by this look like: > > > https://github.com/betaflight/betaflight-configurator-nightlies/releases I think that would be an excellent outcome. Would you be willing to add this to our GitHub Actions? Or would you prefer if I tried my hand on this (that won't happen for a day or two - I just came back from Japan and have a bunch of other stuff to catch up on > The Windows version of build 262 is working just fine in a VM running Windows > 10. Thanks for testing. > The APK version of build 262 works just fine for me on an older Xiaomi Redmi > Note 7 running Android 10. Ditto >> The app looking hung could be the initial connection / initial download from >> the cloud. There isn't enough visual feedback for that. > > > This is only a problem if you have to uninstall the app and then re-install - > like when moving from the store app to a sideloaded version and encountering > a new signing key because of this. If we manage to use the same signing for > all of our nightly builds people will be able to upgrade between them without > a uninstall / reinstall, and avoid having to re-authenticate and re-download. IIRC the builds are completely unsigned. At a minimum we'd have to create a release counter that's monotonic - it seems that the setup for betaflight-configurator already has that somewhere... I haven't looked. >> But I'm not planning to do any UI changes until we have things working with >> Qt6 which will be a while. > > Maybe a 'quick win' temporary fix for this would be to add a warning about > this to the 'Testing cloud credentials' prompt? Sure, that seems straight forward enough In summary: - we need a monotonic, automatic release counter - we should use that for all releases, regardless of platform - we should switch to the date / counter naming scheme on all platforms - we could add a warning to the mobile builds that there may be a fairly long time where the app will look dead Am I missing anything? Would you be willing / interested to handle any (or all ) of that. Thanks /D___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: "rolling" release artifacts on GitHub
Hi Dirk. On 8/12/23 08:21, Dirk Hohndel via subsurface wrote: As Michael and I try to improve the way we post binaries for people to test and use, following up on the Ubuntu and Fedora binaries I mentioned earlier, we now have binaries posted on GitHub as "daily" or "latest" releases: https://github.com/subsurface/subsurface/releases/tag/latest There is an oddity about the way this works. GitHub only does releases for tags. So there are basically two options: (a) do a "latest" tag and post all the binaries under that (which is what I've done so far) (b) create a tag for every merge / push to the master branch Both have drawbacks: (a) creates a real mess with quickly having many, many artifacts in that same 'latest' release and the user having to figure out which ones to download. (b) creates a real mess as the git repo gets flooded with new tags - but then the releases themselves look much more sane I'm curious what people think would be the better strategy - or if there's a third option that I've missed. I have used (b) in the past, and gone for a concatenation of a datestring with a counter - this results in release numbers that make it obvious how recent they are, which is an advantage when trying to help people reporting a problem. It also seems to be possible to create release with an indicative name without having to add it as a tag in the repository - at least when using GitHub actions to create the release: https://github.com/betaflight/betaflight-configurator/blob/07da3398426b5d6f1e0bd74d37f0e6f0cd622c39/.github/workflows/nightly.yml#L55 This is how the releases created by this look like: https://github.com/betaflight/betaflight-configurator-nightlies/releases I'd also appreciate if people could try these new and improved Windows builds (they use a fresh build container with the very latest Qt5.15 libraries, newer compiler, and several other newer dependencies compared to those that I posted last week. I'd be especially interested if there are any improvements to BT / BLE handling, as there were numerous updates to the corresponding code in Qt. The Windows version of build 262 is working just fine in a VM running Windows 10. And I'd love to know how the Android APK works for people trying to side-load Subsurface-mobile onto an Android device. In one quick test for me it seemed to be fine (if awkward and annoying) - but I'd love to make sure a few more people with non-Google devices try this (for reasons of personal preferences I only tend to use plain Google Android devices... therefore I'd love to make sure that this works with Samsung or devices as well. The APK version of build 262 works just fine for me on an older Xiaomi Redmi Note 7 running Android 10. The app looking hung could be the initial connection / initial download from the cloud. There isn't enough visual feedback for that. This is only a problem if you have to uninstall the app and then re-install - like when moving from the store app to a sideloaded version and encountering a new signing key because of this. If we manage to use the same signing for all of our nightly builds people will be able to upgrade between them without a uninstall / reinstall, and avoid having to re-authenticate and re-download. But I'm not planning to do any UI changes until we have things working with Qt6 which will be a while. Maybe a 'quick win' temporary fix for this would be to add a warning about this to the 'Testing cloud credentials' prompt? https://github.com/subsurface/subsurface/blob/e26dd301656400e1355fad7bac158fe48aa6b868/mobile-widgets/qmlmanager.cpp#L692 Cheers Michael Keller ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Divesoft integration testing
On 09 December, 2023 - Philippe Massart via subsurface wrote: > > Le 9 déc. 2023 à 10:57, Jef Driesen a écrit : > > > > On 8/12/2023 20:56, Philippe Massart via subsurface wrote: > >> Since several years now, I import .DLF files from my Divesoft Freedom > >> computer without any problem. > >> I saw that Divesoft Freedom and Liberty where integrated into > >> libdivecomputer, and that a next release of Subsurface could include > >> direct download from the dive computer, instead of manually import .DLF > >> files. > >> For now (test version from November 21th), Divesoft computers are well in > >> this list of supporter computers but no import is available, perhaps > >> because no mount point is available: the mount point showed is the one > >> from my other computer (Garmin), and no change or manual selection is > >> possible (see attachment). > >> My Divesoft computer mount point on Mac is /Volumes/FREEDOM, and > >> /run/media/username/FREEDOM under Linux > >> If there is something to test about that, don’t hesitate to tell me. > > > > The libdivecomputer integration is for downloading dives over bluetooth > > (BLE). That's why the mount point control is disabled, because it's not > > used for bluetooth communication. This feature is only available in the > > newer versions of the Freedom and Liberty. For the older models, which are > > using USB mass storage, you can import the DLF files as before. The > > download over bluetooth will simply download the same content as the DLF > > files, so there is no difference in the data that gets downloaded. The libdivecomputer based downloader and the subsurface DLF importer have different "heritage", the later started as me reverse engineering the format. That's also sort of the background why it stopped at a data importer and never grew up to be a propper "download from dive computer" backend. Nowadays it might be a idea to drop the subsurface DLF parser, and extend libdc_buffer_parser to feed the DLF into libdivecomputer instead and let it parse them. One could write a "download from dive computer" back end either using the libdivecomputer parsing akind to the Uemis Zurich downloader, which also takes a mount point as io-endpoint instead of serial or bluetooth. This would most likely improve the experience the most for Divesoft divers importing logs into subsurface. Or, after a bit of digging, write a Divesoft downloader which uses the DC_TRANSPORT_USBSTORAGE thingie to iterate over DLF files, like the Garmin ones. Or maybee it's time for upstream libdivecomputer to get a variant of DC_TRANSPORT_USBSTORAGE and use that? //Anton ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Divesoft integration testing
Thanks ! It much clearer! Philippe > Le 9 déc. 2023 à 10:57, Jef Driesen a écrit : > > On 8/12/2023 20:56, Philippe Massart via subsurface wrote: >> Since several years now, I import .DLF files from my Divesoft Freedom >> computer without any problem. >> I saw that Divesoft Freedom and Liberty where integrated into >> libdivecomputer, and that a next release of Subsurface could include direct >> download from the dive computer, instead of manually import .DLF files. >> For now (test version from November 21th), Divesoft computers are well in >> this list of supporter computers but no import is available, perhaps because >> no mount point is available: the mount point showed is the one from my other >> computer (Garmin), and no change or manual selection is possible (see >> attachment). >> My Divesoft computer mount point on Mac is /Volumes/FREEDOM, and >> /run/media/username/FREEDOM under Linux >> If there is something to test about that, don’t hesitate to tell me. > > The libdivecomputer integration is for downloading dives over bluetooth > (BLE). That's why the mount point control is disabled, because it's not used > for bluetooth communication. This feature is only available in the newer > versions of the Freedom and Liberty. For the older models, which are using > USB mass storage, you can import the DLF files as before. The download over > bluetooth will simply download the same content as the DLF files, so there is > no difference in the data that gets downloaded. > > Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Divesoft integration testing
On 8/12/2023 20:56, Philippe Massart via subsurface wrote: Since several years now, I import .DLF files from my Divesoft Freedom computer without any problem. I saw that Divesoft Freedom and Liberty where integrated into libdivecomputer, and that a next release of Subsurface could include direct download from the dive computer, instead of manually import .DLF files. For now (test version from November 21th), Divesoft computers are well in this list of supporter computers but no import is available, perhaps because no mount point is available: the mount point showed is the one from my other computer (Garmin), and no change or manual selection is possible (see attachment). My Divesoft computer mount point on Mac is /Volumes/FREEDOM, and /run/media/username/FREEDOM under Linux If there is something to test about that, don’t hesitate to tell me. The libdivecomputer integration is for downloading dives over bluetooth (BLE). That's why the mount point control is disabled, because it's not used for bluetooth communication. This feature is only available in the newer versions of the Freedom and Liberty. For the older models, which are using USB mass storage, you can import the DLF files as before. The download over bluetooth will simply download the same content as the DLF files, so there is no difference in the data that gets downloaded. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
