ci_windows.yaml: builds specific libtorrent releases instead of latest commits of each branch

[Obegg]

qBittorrent/.github/workflows/ci_windows.yaml

Line 21 in fb4b266

libt_version: ["2.0.11", "1.2.20"]

It grabs the release of libtorrent 2.0.11 and 1.2.20, not the latest commits on each branch (RC_2_0 and RC_1_2).
I thought that by downloading a qBittorrent nightly build it also uses the latest commits of each version of libtorrent.
Is there a reason it's using the specific release and not latest commits from each branch?

[qBittUser]

Is there a reason it's using the specific release and not latest commits from each branch?

Something similar should have been the title and instead of 'general' discussion, it should be changed to Q&A. Currently all OS builds in GitHub are made using released stable libraries/dependencies, not just Windows and libtorrent.

I think it's done like this because:

• Quicker to build when only specific version is cached.
• To maintain compatibility with a specific supported version.
• To avoid GitHub cache filling up too often.
• To avoid unexpected additional issues whenever someone submits a new code change.

Otherwise it would be inconvenient if anyone testing a development nightly qBittorrent build would also have to constantly recheck if unreleased libtorrent is or isn't causing issues.

Although it would be nice if there could be additional download options added, then wouldn't have to constantly do extra forked builds to get extra fixes.

[xavier2k6]

you should also consider adding info about the need of a GitHub account to download artifacts

There's a hint on the download link but I made it more visible next to links for transparency.

---

and the need of installing latest Visual C++ Redistributable if using Windows.

Ahh, I forgot that....

---

Also download page mentions that stable release installers include only Boost 1.88, yet news page under the Library versions shows Boost: 1.86 / 1.88 libraries.

Will take a look.

---

If currently no plans for multiple development build download choices with both the minimum supported, what's planned in the next release or latest commits of certain dependencies/libraries, then a summary comment should be added and then this discussion should be marked as answered and closed.

I'll come back to you on this.

[glassez]

Moreover, new libtorrent releases are definitely much less frequent than wanted.

Right, but nonetheless I don't want to debug libtorrent issues in a qbt PR. No matter libtorrent has frequent update or not.

I don't mind manually selecting a specific libtorrent commit instead of blindly using the HEAD of the branch. However, I don't like the idea of using only the releases. It's common for libtorrent to have some bug fixes merged for months before the next version is released. Therefore, it's strange (even foolish) not to utilize these available bug fixes.

[thalieht]

Also download page mentions that stable release installers include only Boost 1.88

Looks like an oversight.

[Chocobo1]

I don't mind manually selecting a specific libtorrent commit instead of blindly using the HEAD of the branch.

In fact, I don't mind it either. But also, I'm not going to keep it up to date. I'll leave this task to others.
Also, shouldn't CI still cover the minimum supported version to ensure it still compiles?

However, I don't like the idea of using only the releases.

I see it this way: If libtorrent release contains some bug then the lib author should release a fix for it. It is their responsibility to maintain it bug-free for their releases. If we included a commit that is not released yet and it goes wrong then the blame is on us.

[Obegg]

If we included a commit that is not released yet

According to https://www.qbittorrent.org/download - We already include a commit that is not released yet.

For libtorrent 2.0.11 it includes arvidn/libtorrent@122c6edb33
For libtorrent 1.2.20 it includes arvidn/libtorrent@3ae563b043

[xavier2k6]

👍 Please submit a PR to the website repo.

Will do.

Done! -> qbittorrent/qBittorrent-website#249

[xavier2k6]

@glassez @Chocobo1 It'd be helpful if I & others could have admin rights to discussions for the creation of "Announcements"

[Chocobo1]

Unfortunately, only the maintainer has the privilege to grant you this. You'll have to ask him.

[xavier2k6]

@sledgehammer999 ping in relation to my request.

[xavier2k6]

Also download page mentions that stable release installers include only Boost 1.88, yet news page under the Library versions shows Boost: 1.86 / 1.88 libraries.

Will take a look.

@glassez @thalieht Can you confirm on linux builds that official releases use both 1.86/1.88 for Boost?

Windows does & macOS is still using 1.86 for both builds since here it's still stuck on 5.0.5

[thalieht]

@glassez @thalieht Can you confirm on linux builds that official releases use both 1.86/1.88 for Boost?

If there are any distributions that support libtorrent 1.2 then you know they have no choice but to keep boost 1.86 around arvidn/libtorrent#7875

[xavier2k6]

I know 1.86 has to be used for libtorrent 1.2, but I can't check if boost 1.86 was used for 2.0.x based build too....hence why I asked for confirmation

[thalieht]

I only know that arch doesn't support libtorrent 1.2 officially so there is no need to stick to boost 1.86.

[xavier2k6]

@Obegg Latest qBittorrent with latest libtorrent (RC_2_0 & RC_1_2) based Builds for (Windows) below:

Latest qBittorrent master commit: 93a7267
Latest libttorrent RC_2_0 commit: arvidn/libtorrent@1b5ab9f
Qt: 6.9.2
Boost: 1.89.0
OpenSSL: 3.5.2
zlib: 1.3.1

https://github.com/xavier2k6/qBittorrent/actions/runs/17513515033/artifacts/3943629776

---

Latest qBittorrent master commit: 93a7267
Latest libttorrent RC_1_2 commit: arvidn/libtorrent@3ae563b
Qt: 6.9.2
Boost: 1.86.0 (libtorrent 1.2.x has incompatabilities with Boost 1.87.0+), so therefore it's pinned.
OpenSSL: 3.5.2
zlib: 1.3.1

https://github.com/xavier2k6/qBittorrent/actions/runs/17515148559/artifacts/3943979711

[Obegg]

I was hoping to get more builds such as this one.
Do you think it will be possible to get daily/weekly/per commit pushed to the main repo builds that will be up to date?
Because the current build is already behind the main repo (a few PRs have been merged).

[qBittUser]

You can always create your own fork, use other users workflow file as example what to change and manually push sync and keep eye on whenever a new dependency version is released.

[xavier2k6]

I was hoping to get more builds such as this one.

Such as?

Do you think it will be possible to get daily/weekly/per commit pushed to the main repo builds that will be up to date?

• I don't think daily/nightly is of any real benefit
• weekly/bi-weekly (yes)
• per commit - say, out of band requests from a weekly/bi-weekly schedule (yes - manual trigger ie workflow_dispatch)

We also must take in to account certain constraints such as that only 5 macOS builds can be run/build at a time (we are currently building/testing with 4)

Because the current build is already behind the main repo (a few PRs have been merged).

This is why I don't think daily/nightly is of any real benefit, because let's say you want to test those recent commits right now immediately......you'd have to wait for the next scheduled "nightly" release for them to become available to you, request someone to provide a build to you or fork repo/compile them yourself & some of the commits like the recent pushes have no impact on end-user's, they are some behind-the-scenes work.

Also note, that you're not going to have the latest & greatest of each dependency upon it's immediate release.
Take OpenSSL for example - in Windows we rely on VCPKG to provide this dependency, we do not build it from source.

• Say OpenSSL 3.5.3 gets released today.

1. A user would have to request VCPKG to update it unless a team member is aware & works on the update.
2. It takes time to update/merge & this can take days to merge
3. Once merged, it becomes available to use in VCPKG, however we rely on the GitHub Actions Runner-Images installed VCPKG version.
4. This version may be out-dated in current image & next deployable image because VCPKG's release didn't sync with GitHub's schedule.
5. These runner images are updated ~weekly, so we'd have to wait for the following week.

So, as you can see CI builds will nearly always have some bit of drawback.

[Obegg]

Such as?

Sorry if I wasn't clear, I meant this kind of builds (where every dependency is up-to-date) and more frequent builds, not just this one.

let's say you want to test those recent commits right now immediately......you'd have to wait for the next scheduled "nightly" release for them to become available to you

Correct, that's why I suggested "per commit".
I'll give you two examples:

1. mpv:

Checks the mpv repository every hour for updates. If there is an update and it is relevant to the windows build, it will automatically run the compilation and release it on success.

2. yt-dlp-master-builds:

This repository hosts releases for the master channel for yt-dlp.

You said:

request someone to provide a build to you

A valid suggestion, the only problem is who to ask (and when), someone would have to provide (or rather automate) builds, and make sure to manually update the yaml file so that each dependency is the latest one (so basically we need a maintainer for that).
But if such builds do come to exist - Shouldn't it come from someone who knows what he's doing (for example: you), or rather some other member of qBittorrent?
This raises another question - Why they need to provide a build "only to me" when in fact such builds can serve a lot more users? And if those builds become frequent and usable - why not add those to qBittorrent website and allow users to download them and name it (as you plan on doing tomorrow to the "nightly" text on that other PR) to an appropriate name?

some of the commits like the recent pushes have no impact on end-user's, they are some behind-the-scenes work.

Sure, true, not EVERY commit has huge impact, I agree, but there will come a moment where a good commit (bug fix/feature/improvement) will be pushed.
I don't think your claim should negate (disqualify) the justification for a builds per commit.
Just because right now some of the commits don't really change much, it doesn't mean that every commit in the future will not change much.

Take OpenSSL for example - in Windows we rely on VCPKG to provide this dependency, we do not build it from source.

Thank you for the detailed explanation, very informative.
Honestly you make a good point there, all I can say is that while qBittorrent does use OpenSSL, even the official build doesn't use the latest version of it, so even if there's a a slight delay (compared to the official qBittorrent build) in updating OpenSSL version in qBittorrent - It's worth it because the (up-to-date, daily/weekly/per commit) builds (ideally) will get it even before a new official qBittorrent build will be released.

[qBittUser]

@Obegg

someone would have to provide.

Until someone does you can easily do it yourself. It's not difficult to lookup what's the latest versions and update them in your own GitHub fork.

If you're afraid of sudden data loss, then better to stick with stable release branch GitHub builds, although it's updated less frequently and many dependencies are quite often older than official release or what's in main master branch development alpha builds.

Unfortunately you can easily only specify libtorrent, Boost and Qt versions in current workflow file. If want latest libtorrent commits then that's easy to change.

OpenSSL, even the official build doesn't use the latest version of it.

If you meant latest stable release installers, then they where made available long ago and quite often uses the latest OpenSSL that was available at that time when installer was built. If there was a change, then I would expect qBit installer version number and release date in news page to also be changed.

will get it even before a new official qBittorrent build will be released.

No, because sometimes it's the opposite. It was explained before your comment.

Why they need to provide a build "only to me" when in fact such builds can serve a lot more users?

Because not everyone needs it.

If anyone does start to provide more builds consistently or if more download choices are added to official workflow file, then I wrote before that it would be good if there would be at least 3 choices to help everyone find regressions sooner. One download option built with oldest still supported, second with what's in current or planned in the next minor or major release and third option with latest commits.

The purpose of current development builds and why some dependencies are rarely updated in them was written before if you reread all previously written other users comments.

[Obegg]

CI build (https://github.com/qbittorrent/qBittorrent/actions/workflows/ci_windows.yaml?query=branch%3Amaster+event%3Apush) uses the following:

Official build (qbittorrent_5.1.2_qt6_lt20_x64_setup.exe) uses the following:

Boost and OpenSSL are not the same.
Offical build uses Boost 1.88.0
CI build uses Boost 1.86.0
Offical build uses OpenSSL 3.5.0
CI build uses OpenSSL 3.5.2

According to #23237 (comment):

1. Release Builds will use whatever latest dependencies are available upon the day that the qBittorrent's release's are created.
2. The Release Builds dependencies vary depending on what libtorrent version is being used & which OS.
3. CI Builds have been specifically pinned at Boost 1.86.0 due to incompatibilities with libtorrent 1.2.x as of Boost 1.87.0
4. CI Builds will use whatever latest dependencies are available via the Runner-Images, VCPKG etc. unless pinned.

[qBittUser]

You have a working example of a single Windows CI GitHub workflow to build qBit successfully with a specific OpenSSL, different libtorrent and different boost version?

[xavier2k6]

You have a working example of a single Windows CI GitHub workflow to build qBit successfully with a specific OpenSSL, different libtorrent and different boost version?

Are you asking me?

[qBittUser]

Are you asking me?

@xavier2k6 Whoever knows if and how it's possible.

Currently it seems @Obegg only has mentioned one repository multiple times, but it doesn't use what qBittorrent needs, so maybe it's bad example.

I guess @Obegg doesn't know much about how GitHub workflows work, maybe skipped many comments, misunderstood a lot or just wasn't satisfied with what was written earlier by others.

Probably better to continue discussion focus in the other comment thread: #23168 (reply in thread)

[xavier2k6]

and the need of installing latest Visual C++ Redistributable if using Windows.

Ahh, I forgot that....

I will create another PR to add this.

Also download page mentions that stable release installers include only Boost 1.88, yet news page under the Library versions shows Boost: 1.86 / 1.88 libraries.

Will take a look.

I will create another PR to rectify this. - Edit: qbittorrent/qBittorrent-website#252

[xavier2k6]

Perhaps the libtorrent 1.2.x/RC_1_2 & 2.0.x/RC_2_0 CI Builds can be segregated out into their own workflows as well as by arch.

---

---