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
