-
-
Notifications
You must be signed in to change notification settings - Fork 557
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release package compatibility #4764
Release package compatibility #4764
Conversation
Impressive piece of work. As it's WIP, I'll hold with mering. |
@pawelsalawa Generally, I am satisfied with the resulting builds. You can see and test them at https://github.com/tuffnatty/sqlitestudio/actions . The Linux build has multiplied: now there are 5 workflows you have to run in sequence if running for the first time. The new four workflows build the runner container and SQLiteStudio's bundled dependencies. Probably the dependency workflows should be merged in one (Qt takes an hour, the others take a couple of minutes each) but it has been easier to debug separately so far. Bundling Python 3.9 on MacOS is a questionable decision. If we bundle it ourselves why not 3.11? Did not try it yet but 3.10 worked well on one occasion. For the slim package, I think it would be better to let user choose their desired Python shared library in configuration and link to it dynamically (discussed in #4662), but if it has not become possible with the recent versions, I would suggest shipping 3 plugin versions. Keeping the numerous Qt's dependency versions in the MacOS workflow may be boring, but until the distfiles cache is cleared it should not be necessary. Probably can also be automated. |
Will the Qt have to be built more than once? I imagine it would be required only if anything changes in Qt, right? (like version, or patches applied) Python 3.11 - the problem here will be C API or ABI compatibility. I don't remember exactly right now, because it's been a while now since I worked on Python plugin, but I remember that I was surprised, that the API compatibility is not out of box when going with newer versions. It's something worth trying and verifying (if the plugin loads to SQLiteStudio, it should be fine). |
Yes, the plan is to keep the build cached until Qt version change or new patches. I also think the old build artifacts are occasionally cleaned automatically, and an infrequent scheduled rebuild should help here. |
4cbd283
to
4854d2a
Compare
@pawelsalawa I have included the small dependencies (ICU, OpenSSL, and Tcl) to the container image, leaving us with just 3 Linux workflows and 12 commits to review. |
91de418
to
35f07f5
Compare
While I admire the effort and beauty of having various variants of builds (different Qt versions, different glibc versions on Linux), is it really profitable? I mean since glibc_2.23 will work on both older and newer Linux (if I understand it correctly), then is it worth to build the others, which are not as portable? Also if we can have Qt 5.15.9, why keeping 5.15.2? If there are good reasons, I'm okay with it. Otherwise I think it will be waste of space and GitHub actually does limit it (it charges a fee for everything over 500MB currently stored in all action artifacts). I have a cleanup job in place, but having so many artifacts has significant impact on how long artifacts can be kept. We can keep all the action code that builds other variations as commented code - just in case. What do you think? |
As I go through the lin_release now, I think that removing the Qt 5.15.2 completely from the workflow would significantly simplify this workflow and - if I'm not mistaken - would enable the Qt 5.15.9 to be included in docker images, thus making it more persistent across subsequent release builds, right? |
@pawelsalawa Of course it's not directly profitable but helps to ensure the builds are compatible with a variety of environments. I have just removed some extra Linux builds leaving only Xenial/Qt-5.15.9 and Bionic/Qt-5.15.2. The 5.15.2 build uses the same Qt binaries provided by aqtinstall as the old build, so I thought it can probably help to catch any problems with the new build during the transition period. Naturally, removing it will make the code a bit cleaner. |
@tuffnatty Okay, that makes sense. Let's keep it for now. And you're right about no limits for public repos. I wasn't aware of that. |
Well, the Windows builds definitely used to start at one moment, but then something changed... will check soon. |
…bundled Qt 5.15.9 and ICU 72.1
…oloured background
… macOS 10.13+ compatible image and installer with Qt 5.15.8. Added macOS 10.12 compatible image and installer with Qt 5.13.2. Added DMGs with bundled Python to the release workflow. This fixes DbSqliteCipher, ScriptingTcl on a good portion of macOS installs. Their dependencies were incompatible with macOS 10.13 since version 3.3.0 and with macOS 10.14-10.15 since commit 3183669. Fixes: pawelsalawa#3991, pawelsalawa#4234.
fb95ebe
to
a2fec16
Compare
Windows builds are working again. |
I confirm that now the Windows builds work. I see you've removed the WIP prefix. Shall I do one more review and merge, or do you foresee some additional commits? |
|
Since we agreed to support more than one Qt version in release packages, I think we should stay with Qt outside of the container. In that case I will have one last look (not now, but soon) and merge. This is really great piece of work you've done here. Thank you! |
@tuffnatty Hi, would you mind checking why some Windows builds failed? https://github.com/pawelsalawa/sqlitestudio/actions/runs/4910709807 and https://github.com/pawelsalawa/sqlitestudio/actions/runs/4910827559 You may probably have better/quicker guess. I took a look, but I have no quick answer. |
See PR #4792. I also do not quite understand what was happening there but It got fixed by switching to msys2 bash for compiling. |
This is a long patch set, and probably it could be better structured. What it gives is: