Also add new job version flag to allow vcpkg dependencies to be reinstalled whenever the job version flag is bumped.
Fix for #17788.
Also add new job version flag to allow vcpkg dependencies to be reinstalled whenever the job version flag is bumped.
Fix for #17788.
Is there no way to hardcode the compiler version and then bump it together with the qt binaries? Otherwise it will be an endless cat-mouse game with appveyor/GitHub CI
Also add new job version flag to allow vcpkg dependencies to be reinstalled whenever the job version flag is bumped.
@MarcoFalke how would it work with tracking the compiler version?
The Qt binaries have to be rebuilt manually so even if the CI job detects the compiler on the build image has changed the best it can do is display a better error message.
An additional complicating factor is Visual Studio is new getting updated as frequently as every two weeks. Not every update causes an ABI incompatibility. This particular issue has come about in Visual Studio 2019 16.4. The 16.1, 16.2, 16.3 and other minor version updates didn't break ABI compatibility.
I don't think it's a coincidence that since "automated" CI became a thing DevOps roles have also taken off. The latter to look after the former. We're in the same boat. Over time I'd expect the "automated" CI's will start adding features like detecting vcpkg and other dependencies being out of date and automatically reinstalling.
Testing... Step "Update vcpkg and install packages" took 23 minutes.
@hebasto that's right. To resolve the libzmq ABI error the safest thing to do is to reinstall all the vcpkg packages. If the job is successful the vcpkg install directory will be cached and the step will be skipped on subsequent builds.
@sipsorcery The excerpt from the log of the "Build" step:
Component too big for incremental LTCG with 32-bit toolset, build without incremental LTCG; Consider switching to 64-bit toolset.
It is weird, isn't it?
That warning has always been there. I've never worried about it. I guess it's because the GitHub and Appveyor vm's load a 32 bit msvc build environment. It doesn't affect the code generation since the build job set the target architecture as 64 bit.
Seems there's an easy fix. I'll test it out.
If the job is successful the vcpkg install directory will be cached and the step will be skipped on subsequent builds.
The first job is successful. But it seems the vcpkg install step is not skipped on subsequent builds.
Something wrong with cache?
UPDATE The excerpt from the log of "Post actions/cache@v1" step:
Post job cleanup.
"C:\Program Files\Git\usr\bin\tar.exe" -cz --force-local -f d:/a/_temp/5482216c-afb5-4ca3-92d5-879e4115cda0/cache.tgz -C C:/jobversion/$JOB_VERSION .
/usr/bin/tar: C\:/jobversion/$JOB_VERSION: Cannot open: No such file or directory
/usr/bin/tar: Error is not recoverable: exiting now
[warning]The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2
@MarcoFalke how would it work with tracking the compiler version?
Instead of runs-on: windows-latest I was hoping for something like windows-msvc-16.2, so that we know exactly which compiler is used.
@sipsorcery Testing 1b1b8a523a8fac05fe7f3c6e287d5a8360cc8900
The excerpt from the log of "Run actions/cache@v1" step on a subsequent build:
Run actions/cache@v1
with:
path: C:/jobversion/1
key: jobversion
env:
PYTHONUTF8: 1
QT_DOWNLOAD_URL: https://github.com/sipsorcery/qt_win_binary/releases/download/v1.6/Qt5.9.8_x64_static_vs2019.zip
QT_DOWNLOAD_HASH: 9a8c6eb20967873785057fdcd329a657c7f922b0af08c5fde105cc597dd37e21
QT_LOCAL_PATH: C:\Qt5.9.8_x64_static_vs2019
VCPKG_INSTALL_PATH: $env:VCPKG_INSTALLATION_ROOT/installed
PLATFORM: x64
JOB_VERSION: 1
pythonLocation: C:\hostedtoolcache\windows\Python\3.7.5\x64
Cache not found for input keys: jobversion.
Instead of
runs-on: windows-latestI was hoping for something likewindows-msvc-16.2, so that we know exactly which compiler is used.
From GitHub Actions Docs:
Available GitHub-hosted runner types are: Windows Server 2019 |
windows-latest
Concept ACK, I guess
Concept ACK.
This PR is not ready for merge. The job version mechanism is not working. The GithHub cache action does not work the way I expected.
I'm still working on a fix.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Closed in favour of #17793.