Conversation
|
Oh, very nice... from the build log that looks like attempt 2 did it ;) Then should be able to do something like v2.8.0-PR1887 or something instead of merge :) btw, for the tags, am I right in thinking that for 2.8.0, since the tag for say RC1 will be Also, I just realised another side effect of this... altering the suffix also propagates through to |
Unfortunately it does not work (yet) - still only
Indeed, I will look into this, as this is a good idea to split the suffix into own variable. |
7205ea7 to
a2f42b8
Compare
Prioritize EDGETX_VERSION_TAG, if set, else resort to EDGETX_VERSION_SUFFIX, if set. Adjust also firmware_version and boot_version strings and adjist bootloader title.
|
I hope to have addressed all issues. This is the result, when flashed on physical TX16S mkII with the GitHub build from this PR: The same sourcetree, built locally and flashed on TX16S mkII: Bootloader flashed with the binary built by this PR in GitHub: Bootloader display, when selecting the firmware binary from this PR: Bootloader display, when selecting the self-built binary: The beginning of I have not yet tested nightly (I guess possible only after this PR is merged) or the tagged builds (could do a test tag and then delete it later). |
|
the whole text should be visible - maybe add a posibility to select it and click on it to see all the info? |
|
Displaying text longer than the display width could be solved with a slowly scrolling text, but this is an idea for a further PR. |
|
Scrolling would be nice... and I think it should be bundled into one PR, why to create another one? Now it is only a partially done. |
Omit GIT SHA from version string if a tagged version. Otherwise, show on own line since is too long for 128x64 B&W displays.
|
I don't know if any changes to the bootloader are warranted... long lines have always been a problem there and enough info is conveyed for it without increasing the complexity of its code. For the long version string (which mainly only affects 128x64 B&W screens since they don't have enough width), I've moved the commit SHA to it's own line and it's only shown if it is a non-tagged version (since if it's tagged, it's commit hash is tied to its tag). |
There was a problem hiding this comment.
Fantastic work Risto :) We can certainly push a tag to test it - although I technically the nightly build should trigger that is it is supposed to be a moving tag if I remember the github build process properly. Which now that of I think of that, it makes me think I need to re-add the git hash for tagged B&W builds... I guess we'll find out soon! 🤦 Or, actually no, as the build date is there... may not be such an issue.
edit: looks like the nightly tag might be applied as part of the release action of the nightly build, so a nightly build will come up like the above screenshot. Either that, or the tag is ignored. Will do a test tag for that later in my own repo to see what happens.
* Add PR number to version string * Testing another way * Decide according to GitHub ref type how to parse and where to output. Prioritize EDGETX_VERSION_TAG, if set, else resort to EDGETX_VERSION_SUFFIX, if set. Adjust also firmware_version and boot_version strings and adjist bootloader title. * Consider also B/W. * B&W: omit GIT SHA if tagged, otherwise own line Omit GIT SHA from version string if a tagged version. Otherwise, show on own line since is too long for 128x64 B&W displays. Co-authored-by: Peter Feerick <peter.feerick@gmail.com>












Augments #1850 by adding a pull request number to the version string.