vcpkg debug test for ci(windows): bust vcpkg cache on overlay/triplet/requirements changes#5955
Open
MaxRayskiy wants to merge 58 commits intoci/libzip-zlib-ng-vcpkgfrom
Open
vcpkg debug test for ci(windows): bust vcpkg cache on overlay/triplet/requirements changes#5955MaxRayskiy wants to merge 58 commits intoci/libzip-zlib-ng-vcpkgfrom
MaxRayskiy wants to merge 58 commits intoci/libzip-zlib-ng-vcpkgfrom
Conversation
…5948) * MRZlib: optional properties output (CRC-32 + sizes) on raw compress Adds ZlibCompressProperties { crc32, uncompressedSize, compressedSize } and an optional pointer to it on ZlibCompressParams. Populated only when both non-null and rawDeflate is true — the zlib wrapper already carries Adler-32, so this metadata is only needed for the raw/ZIP path. Collection reuses the already-typed `stream.next_in` / `stream.avail_in` zlib needs, so no new reinterpret_cast. Writing through a pointer under `const ZlibCompressParams&` is fine — only the pointer is const. Tests cover: populated values match crc32Ref/known sizes in raw mode at levels 1 and 9; empty raw input zeroes sizes and CRC while pinning the terminator-block bytes zlib emits; wrapped-mode passes sentinel props through untouched. * MRZlib: address review feedback - Rename ZlibCompressProperties -> ZlibCompressStats; member `properties` -> `stats`. - Struct doc describes its own purpose rather than pointing elsewhere. - Collect CRC-32 + sizes whenever `stats` is non-null, in both wire modes (the zlib wrapper has Adler-32 embedded, but a caller may still want the CRC-32 for external checksums). - No local `collectStats` flag — check `params.stats` directly at each site; drops the redundant "reuse already-typed pointers" comment. - Rename MRTest/MRZlib.cpp -> MRZlibTests.cpp. - Consolidate the three properties tests into two: one parameterized over {raw|wrapped} × {level 1|9} that checks CRC against an independent `crc32Ref` + expected sizes, and one empty-input test covering both modes.
* test: add sphere mesh compress-to-zip test Creates a sphere with ~100K vertices, saves it as a .mrmesh file in a temporary folder, then calls compressZip to produce a .zip archive in a second temporary folder. Verifies: - mesh and zip files both exist and are non-empty - the zip is not absurdly larger than the source (envelope sanity) Serves as a realistic end-to-end exercise of MeshLib's zip write path (libzip + zlib deflate) against mesh-sized data. Suitable for timing comparisons of different zlib backends (e.g., stock zlib vs zlib-ng compat) when added to a run's measurement targets. Placed in source/MRTest/ as MRZipCompressTests.cpp; no CMake changes needed (the existing file(GLOB SOURCES "*.cpp") picks it up). * fix * test: log mesh and zip sizes via spdlog::info * test: add many-small-files zip compression test New GTest case MRMesh.CompressManySmallFilesToZip writes 100 binary files and 100 JSON files to a temp folder (each 60 000 bytes, 12 000 000 bytes total — matching the sphere.mrmesh size from the existing CompressSphereToZip test) and compresses the folder to a .zip. Binary file content is deterministic pseudo-random bytes from a per-index-seeded LCG — low-compressibility, representative of mesh coordinate floats and similar near-incompressible payloads. JSON file content is deterministic structured-looking text padded to exactly 60 000 bytes with trailing whitespace — highly compressible, representative of scene-description metadata and logs. Pairs with CompressSphereToZip so a single run of MRTest produces two direct data points: one-large-file vs many-small-files on roughly the same total byte budget. Useful for assessing libzip's per-entry overhead (separate deflate session, CRC pass, local file header) when comparing zlib backends or compression-level changes. Per-file byte count is constant and deterministic so the aggregate input size and zip size are stable across runs (modulo whatever small variation deflate itself introduces on different zlib builds). Logs totals via spdlog::info for easy diff with the other test. * CompressManySmallFilesToZip test only with 2 times more files * reduce the test time for everyday run * comment
* win: add _ITERATOR_DEBUG_LEVEL=2 distro * test run: build with new matrix * test * test vcpkg mirror for msys * replace mirror files with vcpkg cache * Allow setting the vcpkg triplet for `generate.mk`. * add missing msys2 files * use vcpkg_triplet as job-level env * add getopt * force v142 vc toolset * use s3 mirror for missing files * test x-script for X_VCPKG_ASSET_SOURCES * use s3 as assets provider * use use_s3_assets-provider * trigger build * fix typo * fix s3 dest * use original url to fetch downloads first Signed-off-by: Max Raiskii <max.raiskii@meshinspector.com> * update arg parsing in asset-provider * test disable python build * skip Release build * skip bindings for new triplet * Python tests if matrix.vcpkg_triplet != 'x64-windows-meshlib-iterator-debug' * codereview * fix vcpkg_triplet var * condition extraction * updare example plugin compile * fix WindowsArchive cleanup * addf itterator debug config for full ci and standart builds * update distr test --------- Signed-off-by: Max Raiskii <max.raiskii@meshinspector.com> Co-authored-by: Egor Mikhaylov <egor.mikhaylov@meshinspector.com> Co-authored-by: Fedor Chelnokov <fedor.chelnokov@meshinspector.com>
Creates a sphere with ~100K vertices, saves it as a .mrmesh file in a temporary folder, then calls compressZip to produce a .zip archive in a second temporary folder. Verifies: - mesh and zip files both exist and are non-empty - the zip is not absurdly larger than the source (envelope sanity) Serves as a realistic end-to-end exercise of MeshLib's zip write path (libzip + zlib deflate) against mesh-sized data. Suitable for timing comparisons of different zlib backends (e.g., stock zlib vs zlib-ng compat) when added to a run's measurement targets. Placed in source/MRTest/ as MRZipCompressTests.cpp; no CMake changes needed (the existing file(GLOB SOURCES "*.cpp") picks it up).
The Windows vcpkg cache key was only keyed by matrix.vcpkg-version, so changes to: - thirdparty/vcpkg/ports/** (MeshLib's overlay ports) - thirdparty/vcpkg/triplets/** - requirements/windows.txt - thirdparty/install.bat didn't invalidate the cache. A pre-built C:\vcpkg\installed\ tree was restored verbatim and install.bat's "vcpkg install ..." saw every port as "already installed" (total install time: 3.57 ms in the last PR run), so overlay ports never got consulted. Concrete symptom observed on PR #5932 (zlib → zlib-ng-compat overlay): - Linux-vcpkg (which rebuilds vcpkg inside a Docker image every time `prepare-image / linux-vcpkg-build-upload` runs) picked up zlib-ng; compression tests showed -0.3% zip size and -41 to -45% wall time on Release builds. - Windows vcpkg served the cached pre-zlib-ng tree; zip sizes and test times were indistinguishable from master. Fix: include a hashFiles() of the overlay/triplet/requirements/ install-script content in the cache key. First run after merging this takes the full ~20 min vcpkg install; subsequent runs hit the cache again as before.
Observed in run 24638998286: on Windows, a fresh install of our zlib overlay (triggered by PR #5934 busting the vcpkg cache key) failed with: error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Missing msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst ... 404 from every msys2 mirror Root cause: our portfile called vcpkg_fixup_pkgconfig(), which on Windows invokes vcpkg_acquire_msys to download the pinned mingw-w64-pkgconf package from msys2 mirrors. That particular version has been pruned from the live mirrors; every one of the six fallback URLs 404s. Deterministic failure that re-runs won't fix. The call is not needed by our consumers. Every MeshLib/vcpkg consumer that depends on zlib finds it via the CMake target `ZLIB::ZLIB` exported from lib/cmake/ZLIB/ZLIBConfig.cmake; nobody reads lib/pkgconfig/zlib.pc via pkg-config. The .pc file is still generated by zlib-ng's own CMake, with a correct `Libs: -lz` entry in compat mode - it just doesn't get post-processed. Removing the call sidesteps the msys2 dependency entirely. zlib-ng-compat build steps (cmake configure, cmake install, copy_pdbs, cmake_config_fixup for ZLIB, copyright install) are unaffected.
thirdparty/vcpkg/downloads/ is already used by thirdparty/install.bat
to pre-seed C:\vcpkg\downloads\ with msys2 .pkg.tar.zst archives
that vcpkg pins by SHA512 but msys2 mirrors have rotated out of
their live repos. This adds one more entry:
msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst
SHA512 eb6ba49d56b0edc4f605ad896ac9deb2202c853c821f1c28a26e3c71a5083e893c
8697d174b141da9dc6561620ea218166bd041664d54a0ab51b93bad246ed7a
Pinned by vcpkg 2024.10.21's
scripts/cmake/vcpkg_find_acquire_program(PKGCONFIG).cmake. vcpkg
checks local downloads/ first: if the file exists and its SHA512
matches, the network fetch is skipped. msys2 mirrors currently serve
a newer -N suffix build of the same 2.2.0 upstream, so every pinned
URL returns 404; this workaround unblocks any port that rebuilds
from source and calls vcpkg_fixup_pkgconfig() (blosc, freetype,
libharu, ...).
Note: vcpkg 2026.03.18 (used by the msvc-2022 matrix entries) pins
a completely different URL (pkgconf-2.5.1-1 from the msys repo,
still available); that matrix entry is not affected and no file is
needed for it. This fix is scoped to the 2024.10.21 / msvc-2019
path.
Alternative long-term fix is to bump matrix.vcpkg-version off
2024.10.21. That's a bigger change with wider blast radius; this
PR is the minimal targeted workaround.
…-staged Commit cb1edb5 dropped the vcpkg_fixup_pkgconfig() call from the overlay portfile to work around the msys2 pkgconf 1~2.2.0-1 404. That workaround broke Linux-vcpkg: the unrewritten lib/pkgconfig/zlib.pc left absolute build-tree paths (`-I/root/vcpkg/packages/zlib_x64-linux-meshlib/include`) baked into downstream pkg-config targets, so CMake's PkgConfig::curl imported target pointed at a directory that no longer existed at consumer time, producing: CMake Error in source/MRViewer/CMakeLists.txt: Imported target "PkgConfig::curl" includes non-existent path "/root/vcpkg/packages/zlib_x64-linux-meshlib/include" in its INTERFACE_INCLUDE_DIRECTORIES. Commit e250677 on this branch pre-stages the msys2 pkgconf archive vcpkg 2024.10.21 pins, so on Windows the vcpkg_acquire_msys() fetch inside vcpkg_fixup_pkgconfig() now hits the local file and succeeds instead of 404ing. vcpkg 2026.03.18 pins a different pkgconf build that's still live on msys2 mirrors. Both platforms therefore tolerate an unconditional vcpkg_fixup_pkgconfig() call again. Restore it so Linux-vcpkg gets the `.pc` rewriting it needs.
Run 24670365594 on this branch hit the same msys2 mirror-404 class of failure we saw before, this time on a different pinned package: error: Missing msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst and downloads are blocked by x-block-origin ...404 from all 6 mirrors error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Same mechanism, different file. vcpkg_acquire_msys() downloads an entire msys2 environment (bash, coreutils, file, gawk, grep, gzip, diffutils, make, pkgconf, sed — plus transitive deps like msys2-runtime), each pinned by SHA512 to a specific build. msys2 mirrors rotate old builds out of their live repos. We already pre-staged pkgconf in #5943; this commit adds the msys2-runtime file that failed next. File: msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst SHA512: 35fd12556a53aa57d8f9500c5c98d5e1fc64c6fbba34cc97e2ff78893e5b1b63c 417bc1c8d1e62b26b2a93aef120fa1f9f82aad67dff4cc44af169d0d29d68f7 Matches the pin in vcpkg 2024.10.21's scripts/cmake/vcpkg_acquire_msys.cmake (line 444-445). thirdparty/install.bat copies thirdparty/vcpkg/downloads/ into C:\vcpkg\downloads\ before vcpkg install; vcpkg_download_distfile() checks the local file first and skips the network fetch if the SHA matches. Same caveat as with the pkgconf pre-staging: this is a point fix. vcpkg_acquire_msys() pulls several more packages that are equally exposed to msys2's retention policy; if any of those also fail in a future run, they will need the same treatment. A bigger fix (bump matrix.vcpkg-version off 2024.10.21 onto a release with still-live msys2 pins) is out of scope for this branch.
The previous push (db7e6c0) triggered a workflow event before skip-image-rebuild label was applied to this PR, so the current run (24680023870) rebuilt all images unnecessarily. This commit adds an empty marker comment so a new workflow event fires with the label in the event payload, gating off the three need_*_rebuild flags. Consumer jobs will pull the existing images pushed by the previous (successful) prepare-image run. Marker comment will be removed in a cleanup commit once CI confirms the skip path works.
Bumps [astral-sh/setup-uv](https://github.com/astral-sh/setup-uv) from 8.0.0 to 8.1.0. - [Release notes](https://github.com/astral-sh/setup-uv/releases) - [Commits](astral-sh/setup-uv@cec2083...0880764) --- updated-dependencies: - dependency-name: astral-sh/setup-uv dependency-version: 8.1.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The transform properties panel and its Ribbon header buttons (Reset / Apply / context menu) now operate on the whole selection instead of short-circuiting on multi-selection. - When all selected objects share the same xf, edits are applied to every object under a single CombinedHistoryAction, so Ctrl+Z reverts the multi-object edit in one step. Selection source switched to the new SceneCache::getAllTopmostObjects so a parent-plus-child selection is not moved twice through the parent's cascade. - When the selected objects' xfs differ, the scale / rotation / translation rows render read-only em-dashes via UI::inputTextCenteredReadOnly and cannot be edited. - The Ribbon context menu, Reset and Apply header buttons are available in both cases. Copy / Save-to-file are disabled when the selection has mixed xfs (no shared value to serialise); Paste / Load / Reset / Apply remain enabled since they only write to the selection. - Renamed selectionChangedToSingleObj_ to transformBlockShown_ and simplified the scroll-fix trigger to the "block just appeared" transition, now that the block can appear for multi-selections too. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* RibbonMenu: Add button for changing the UI language * Use ASCII encoding
* fix(emscripten): restore apt mirror swap in builder stage PR #5930 split docker/emscriptenDockerfile into a builder and a final stage. The pre-#5930 Dockerfile executed sed -i 's http://ports.ubuntu.com/ubuntu-ports/ \ http://mirror.eu.ossplanet.net/ubuntu-ports/ ' \ /etc/apt/sources.list before the very first `apt-get update`, redirecting Canonical's arm64 ports mirror to a faster / less geo-restricted alternative. The multi-stage refactor kept that swap in the final stage's apt block but dropped it from the builder stage's apt block, so the builder now pulls `git pkg-config ninja-build gettext` from `ports.ubuntu.com` directly. That is a performance regression on every PR that rebuilds this image. Restore the swap by prepending the sed command to the builder's RUN, matching the original ordering. Final stage is unchanged. * emscripten Dockerfile: drop redundant comment about sed swap The two-line comment above the RUN block explained what the sed command does, which is self-evident from reading the command itself. Keep the comment that's not obvious (why the apt set is minimal and lacks firefox/xvfb/dbus).
after introduction of `segmentIntersectionOrder` in `MRContoursCut.cpp`
The Build step used an `if errorlevel 1 exit 1` check after each
command inside a parenthesized IF block in a cmd.exe batch script.
On windows-2025 runners, that check was failing to catch
`cmake --build` / ninja failures — observed in run 24691107383,
msvc-2019 Release CMake: ninja reported
ninja: build stopped: subcommand failed.
(MRViewer.dll link failed with LNK1120 unresolved externals from
cpr.lib), but the `if errorlevel 1 exit 1` after `cmake --build`
didn't fire, so the script went on to `xcopy` and exited 0. GitHub
Actions marked the step as `success` even though MRCuda.lib and
other targets were never produced. The very next step,
`Generate and build Python bindings`, tried to link `mrcudapy.pyd`
against `MRCuda.lib` and failed with `lld-link: error: could not
open 'MRCuda.lib': No such file or directory` — a confusing error
67 seconds after the real failure the step should have reported.
`if errorlevel 1` inside parenthesized IF blocks in cmd.exe has
well-known parse-time expansion quirks that can cause it to miss
exit codes that were set by commands earlier in the same block.
Replace the pattern with `|| exit /b 1` chained directly onto each
command. `||` is evaluated at process-exit time and doesn't depend
on errorlevel-in-parens semantics. This is the documented idiom
for robust error propagation in cmd.exe batch files.
Functional change: the step now fails fast with the first
command's non-zero exit, instead of running to completion and
reporting success regardless. Applies to all three Windows matrix
entries (msvc-2019, msvc-2022 Debug, msvc-2022 Release). Does not
change behavior when the build succeeds.
Other steps in the same workflow (`Build MRBind`, `Generate C
bindings`, `Generate and build Python bindings`) use similar cmd
batch patterns and may have the same latent bug; left alone here
to keep the PR scoped to the Build step that has a concrete
reproducer. Worth auditing separately.
MaxRayskiy
force-pushed
the
ci/libzip-zlib-ng-vcpkg-debug-test
branch
from
7137168 to
2f153ed
Compare
Adds a MeshLib-specific vcpkg overlay port `thirdparty/vcpkg/ports/zlib`
that shadows the upstream `zlib` port. The overlay builds
zlib-ng/zlib-ng 2.3.3 with `ZLIB_COMPAT=ON`, producing:
include/zlib.h, include/zconf.h
lib/libz.{so,dylib} / z.lib
lib/cmake/ZLIB/ZLIBConfig*.cmake (target ZLIB::ZLIB)
lib/pkgconfig/zlib.pc
i.e. byte-layout-compatible with upstream zlib. Every vcpkg port that
depends on `zlib` (libzip, libpng, openvdb, gdcm, ...) picks up the
faster zlib-ng implementation at link time without source or link-flag
changes downstream.
Output format is standard deflate - HP 3D printer / OPC / 3MF
compatibility is preserved, as are any other consumers of the .zip
files MeshLib produces.
thirdparty/install.bat (Windows) now passes `--overlay-ports` alongside
the existing `--overlay-triplets`, matching the pattern rockylinux8-
vcpkgDockerfile already uses. Rocky side needs no change - its
Dockerfile already does `--overlay-ports=MeshLib/ports`.
Scope deliberately limited to vcpkg (Windows + Rocky). Ubuntu (apt
libz), macOS (brew zlib), and Emscripten (emsdk --use-port=zlib) are
left on stock zlib for this PR. Those paths would each need separate
mechanism changes (apt can't swap libz in place; brew's zlib-ng
formula doesn't install compat symbols by default; Emscripten would
need a new submodule replacing -s USE_ZLIB=1) and deserve independent
measurement. Follow-ups if vcpkg measurement is positive.
Risk notes:
- Some vcpkg ports may declare version constraints on `zlib`. The
overlay keeps "version": "1.3.1" with "port-version": 100, so any
`>=1.3.1` constraint is satisfied. A `==1.3.1` pin would fail on
port-version mismatch; none known in current requirements.
- Upstream zlib-ng compat mode is battle-tested (used in production by
Intel ISA-L, Chromium, ...), but the first build via this overlay is
the validation step. CI on this PR is the test.
Measurement status: NOT measured. CI on this PR is the proof. Compare
image init times AND compression-time-dependent job step timings
(e.g., linux-vcpkg artifacts packaging) against master.
Creates a sphere with ~100K vertices, saves it as a .mrmesh file in a temporary folder, then calls compressZip to produce a .zip archive in a second temporary folder. Verifies: - mesh and zip files both exist and are non-empty - the zip is not absurdly larger than the source (envelope sanity) Serves as a realistic end-to-end exercise of MeshLib's zip write path (libzip + zlib deflate) against mesh-sized data. Suitable for timing comparisons of different zlib backends (e.g., stock zlib vs zlib-ng compat) when added to a run's measurement targets. Placed in source/MRTest/ as MRZipCompressTests.cpp; no CMake changes needed (the existing file(GLOB SOURCES "*.cpp") picks it up).
The Windows vcpkg cache key was only keyed by matrix.vcpkg-version, so changes to: - thirdparty/vcpkg/ports/** (MeshLib's overlay ports) - thirdparty/vcpkg/triplets/** - requirements/windows.txt - thirdparty/install.bat didn't invalidate the cache. A pre-built C:\vcpkg\installed\ tree was restored verbatim and install.bat's "vcpkg install ..." saw every port as "already installed" (total install time: 3.57 ms in the last PR run), so overlay ports never got consulted. Concrete symptom observed on PR #5932 (zlib → zlib-ng-compat overlay): - Linux-vcpkg (which rebuilds vcpkg inside a Docker image every time `prepare-image / linux-vcpkg-build-upload` runs) picked up zlib-ng; compression tests showed -0.3% zip size and -41 to -45% wall time on Release builds. - Windows vcpkg served the cached pre-zlib-ng tree; zip sizes and test times were indistinguishable from master. Fix: include a hashFiles() of the overlay/triplet/requirements/ install-script content in the cache key. First run after merging this takes the full ~20 min vcpkg install; subsequent runs hit the cache again as before.
Observed in run 24638998286: on Windows, a fresh install of our zlib overlay (triggered by PR #5934 busting the vcpkg cache key) failed with: error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Missing msys2-mingw-w64-x86_64-pkgconf-1~2.2.0-1-any.pkg.tar.zst ... 404 from every msys2 mirror Root cause: our portfile called vcpkg_fixup_pkgconfig(), which on Windows invokes vcpkg_acquire_msys to download the pinned mingw-w64-pkgconf package from msys2 mirrors. That particular version has been pruned from the live mirrors; every one of the six fallback URLs 404s. Deterministic failure that re-runs won't fix. The call is not needed by our consumers. Every MeshLib/vcpkg consumer that depends on zlib finds it via the CMake target `ZLIB::ZLIB` exported from lib/cmake/ZLIB/ZLIBConfig.cmake; nobody reads lib/pkgconfig/zlib.pc via pkg-config. The .pc file is still generated by zlib-ng's own CMake, with a correct `Libs: -lz` entry in compat mode - it just doesn't get post-processed. Removing the call sidesteps the msys2 dependency entirely. zlib-ng-compat build steps (cmake configure, cmake install, copy_pdbs, cmake_config_fixup for ZLIB, copyright install) are unaffected.
…-staged Commit cb1edb5 dropped the vcpkg_fixup_pkgconfig() call from the overlay portfile to work around the msys2 pkgconf 1~2.2.0-1 404. That workaround broke Linux-vcpkg: the unrewritten lib/pkgconfig/zlib.pc left absolute build-tree paths (`-I/root/vcpkg/packages/zlib_x64-linux-meshlib/include`) baked into downstream pkg-config targets, so CMake's PkgConfig::curl imported target pointed at a directory that no longer existed at consumer time, producing: CMake Error in source/MRViewer/CMakeLists.txt: Imported target "PkgConfig::curl" includes non-existent path "/root/vcpkg/packages/zlib_x64-linux-meshlib/include" in its INTERFACE_INCLUDE_DIRECTORIES. Commit e250677 on this branch pre-stages the msys2 pkgconf archive vcpkg 2024.10.21 pins, so on Windows the vcpkg_acquire_msys() fetch inside vcpkg_fixup_pkgconfig() now hits the local file and succeeds instead of 404ing. vcpkg 2026.03.18 pins a different pkgconf build that's still live on msys2 mirrors. Both platforms therefore tolerate an unconditional vcpkg_fixup_pkgconfig() call again. Restore it so Linux-vcpkg gets the `.pc` rewriting it needs.
Run 24670365594 on this branch hit the same msys2 mirror-404 class of failure we saw before, this time on a different pinned package: error: Missing msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst and downloads are blocked by x-block-origin ...404 from all 6 mirrors error: building zlib:x64-windows-meshlib failed with: BUILD_FAILED Same mechanism, different file. vcpkg_acquire_msys() downloads an entire msys2 environment (bash, coreutils, file, gawk, grep, gzip, diffutils, make, pkgconf, sed — plus transitive deps like msys2-runtime), each pinned by SHA512 to a specific build. msys2 mirrors rotate old builds out of their live repos. We already pre-staged pkgconf in #5943; this commit adds the msys2-runtime file that failed next. File: msys2-msys2-runtime-3.5.3-3-x86_64.pkg.tar.zst SHA512: 35fd12556a53aa57d8f9500c5c98d5e1fc64c6fbba34cc97e2ff78893e5b1b63c 417bc1c8d1e62b26b2a93aef120fa1f9f82aad67dff4cc44af169d0d29d68f7 Matches the pin in vcpkg 2024.10.21's scripts/cmake/vcpkg_acquire_msys.cmake (line 444-445). thirdparty/install.bat copies thirdparty/vcpkg/downloads/ into C:\vcpkg\downloads\ before vcpkg install; vcpkg_download_distfile() checks the local file first and skips the network fetch if the SHA matches. Same caveat as with the pkgconf pre-staging: this is a point fix. vcpkg_acquire_msys() pulls several more packages that are equally exposed to msys2's retention policy; if any of those also fail in a future run, they will need the same treatment. A bigger fix (bump matrix.vcpkg-version off 2024.10.21 onto a release with still-live msys2 pins) is out of scope for this branch.
The previous push (db7e6c0) triggered a workflow event before skip-image-rebuild label was applied to this PR, so the current run (24680023870) rebuilt all images unnecessarily. This commit adds an empty marker comment so a new workflow event fires with the label in the event payload, gating off the three need_*_rebuild flags. Consumer jobs will pull the existing images pushed by the previous (successful) prepare-image run. Marker comment will be removed in a cleanup commit once CI confirms the skip path works.
The Build step used an `if errorlevel 1 exit 1` check after each
command inside a parenthesized IF block in a cmd.exe batch script.
On windows-2025 runners, that check was failing to catch
`cmake --build` / ninja failures — observed in run 24691107383,
msvc-2019 Release CMake: ninja reported
ninja: build stopped: subcommand failed.
(MRViewer.dll link failed with LNK1120 unresolved externals from
cpr.lib), but the `if errorlevel 1 exit 1` after `cmake --build`
didn't fire, so the script went on to `xcopy` and exited 0. GitHub
Actions marked the step as `success` even though MRCuda.lib and
other targets were never produced. The very next step,
`Generate and build Python bindings`, tried to link `mrcudapy.pyd`
against `MRCuda.lib` and failed with `lld-link: error: could not
open 'MRCuda.lib': No such file or directory` — a confusing error
67 seconds after the real failure the step should have reported.
`if errorlevel 1` inside parenthesized IF blocks in cmd.exe has
well-known parse-time expansion quirks that can cause it to miss
exit codes that were set by commands earlier in the same block.
Replace the pattern with `|| exit /b 1` chained directly onto each
command. `||` is evaluated at process-exit time and doesn't depend
on errorlevel-in-parens semantics. This is the documented idiom
for robust error propagation in cmd.exe batch files.
Functional change: the step now fails fast with the first
command's non-zero exit, instead of running to completion and
reporting success regardless. Applies to all three Windows matrix
entries (msvc-2019, msvc-2022 Debug, msvc-2022 Release). Does not
change behavior when the build succeeds.
Other steps in the same workflow (`Build MRBind`, `Generate C
bindings`, `Generate and build Python bindings`) use similar cmd
batch patterns and may have the same latent bug; left alone here
to keep the PR scoped to the Build step that has a concrete
reproducer. Worth auditing separately.
New GTest case MRMesh.CompressManySmallFilesToZip writes 100 binary files and 100 JSON files to a temp folder (each 60 000 bytes, 12 000 000 bytes total — matching the sphere.mrmesh size from the existing CompressSphereToZip test) and compresses the folder to a .zip. Binary file content is deterministic pseudo-random bytes from a per-index-seeded LCG — low-compressibility, representative of mesh coordinate floats and similar near-incompressible payloads. JSON file content is deterministic structured-looking text padded to exactly 60 000 bytes with trailing whitespace — highly compressible, representative of scene-description metadata and logs. Pairs with CompressSphereToZip so a single run of MRTest produces two direct data points: one-large-file vs many-small-files on roughly the same total byte budget. Useful for assessing libzip's per-entry overhead (separate deflate session, CRC pass, local file header) when comparing zlib backends or compression-level changes. Per-file byte count is constant and deterministic so the aggregate input size and zip size are stable across runs (modulo whatever small variation deflate itself introduces on different zlib builds). Logs totals via spdlog::info for easy diff with the other test.
…om/MeshInspector/MeshLib into ci/libzip-zlib-ng-vcpkg-debug-test
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.