Allow use of online or offline qt installers with configurable mirror. #24
Conversation
This recipe uses the online installer and we're going to add an option for the offline one.
Using the online installer by default.
Instead of separate recipes, I think it's probably worth keeping this change within the recipe in order to make better use of the things that are common between them.
|
@cottsay I know that you had concerns about the fragility of the maintenance tool overall and while this doesn't abandon its use in the online installer it does add the offline installer as an alternative. I'd like to get your thoughts on paper about whether this seems like a reasonable middle ground or if you think that disabling the maintenance tool during online install still needs to be done. |
There was a problem hiding this comment.
It looks like with the Qt 4 installer which was released a couple months back, it may now be possible to do a complete command-line unattended installer on windows. That would help alleviate one of the pain points here, which is the qs script.
https://doc-snapshots.qt.io/qtifw-master/ifw-use-cases-cli.html
| returns [0, 1, 3] | ||
| options %{--st "#{qt_mirror_url}" --script qt-installer.qs --verbose MsvcVersion=2019 ErrorLogname="#{error_filename}"} | ||
| timeout 2000 | ||
| not_if {::File.exist?('c:\\Qt\\Qt5.12.10\\MaintenanceTool.exe')} |
There was a problem hiding this comment.
I think it's possible to specify the install directory of Qt, so they are the same for both offline and online.
There was a problem hiding this comment.
it may now be possible to do a complete command-line unattended installer on windows
That's definitely a good item to put on the backlog: #25
There was a problem hiding this comment.
@cottsay ... I'd like to get your thoughts ...
I'm not entirely convinced that the price we pay for trying to keep at the bleeding edge of Qt releases is worth the benefit, but that's a decision for another forum and a wider audience. Most of my concerns are inherent to the way Qt installs itself as opposed to the way we're invoking it.
IfWhen the Qt installer or maintenance tool blocks the build again, we should be able to unblock the farm faster using this new mechanism. I'm in support of the buildfarmer taking a more service-like approach to the role, and prioritizing completion of builds over investigation into failures, and this change makes that easier to do.
I do think this is a good middle ground. Allocating more resources into improving the story is less appealing to me now that we have a better way to mitigate the damage.
Definitely agreed here. Thanks for the feedback! |
After last week's download.qt.io downtime I threw together #23 which uses the offline installer fetched from a mirror.
This is what I think we should actually do instead of that, which is make the offline installer an option determined by attribute as well as making the qt download mirror an option. I have not integrated the mirror option into the online installer but in theory it could be plumbed through there as well.
This PR replaces #23 but also keeps the online installer as the default now that download.qt.io is back up.