Replace the vcpkg-cache action, whose post step saves even when the job fails or is cancelled, with actions/cache/restore and a save step that only runs after a successful configure.
Rename the python wheel/sdist to rips.whl/rips.tar.gz (dropping the version number) when publishing to the rolling dev-latest release, so the download link stays stable across builds.
Include the dist-python artifact (wheel/sdist built for PyPI) when packaging assets for the rolling dev-latest release, and rename the python-distribution artifact to dist-python for consistency with the dist-<name> naming convention used by other build artifacts.
* Add publish-dev-build job to distribute dev builds to OPM/ResInsight-Builds
* Limit publish-dev-build to schedule and workflow_dispatch events
* Distribute dev builds to CeetronSolutions/resinsight-builds instead of OPM/ResInsight-Builds
* Shorten comments in publish-dev-build job
CMake 4.x on the ubuntu-26.04 runners removed compatibility with
cmake_minimum_required(VERSION < 3.5), and ThirdParty/openzgy/zfp declares
VERSION 3.1 (3.4 on Windows), so configuring fails at
ThirdParty/openzgy/zfp/CMakeLists.txt:4.
zfp is a nested submodule of openzgy pinned at 0.5.5; the first release
declaring a 3.5-or-later minimum is 1.0.0, so clearing this properly means a
major-version upgrade of a compression library and whatever API changes that
brings to the openzgy wrapper. That is worth doing on its own schedule, not as
part of a CI fix.
Pass the policy minimum instead, which is already the established approach in
this repository: ResInsightMac.yml passes the same flag, and both
x64-linux-release and x64-windows-release set it via
VCPKG_CMAKE_CONFIGURE_OPTIONS for the same reason.
A scan of every CMakeLists.txt in the repository and its submodules (excluding
ThirdParty/vcpkg/ports, which the triplets already cover) finds zfp to be the
only remaining declaration below 3.5.
ResInsightWithCache.yml is deliberately left alone: it still runs on
ubuntu-24.04, and its cmake command line feeds the buildcache hash, so adding a
flag there would invalidate the cache for no present benefit. It will need the
same flag when it moves to ubuntu-26.04.
vcpkg builds every port in both debug and release unless VCPKG_BUILD_TYPE says
otherwise, and that variable is only read from the triplet file. The workflows
that already pass -DVCPKG_TARGET_TRIPLET/-DVCPKG_HOST_TRIPLET pointing at a
*-release triplet (ResInsightWithCache, rhel8-unit-tests, rhel8-package,
Dockerfile.rhel8) therefore skip the debug half; the remaining three did not.
clang-tidy and clazy-report passed no triplet at all and so used the plain
x64-linux triplet, building every port twice. Both only need
compile_commands.json, so the debug half was pure cost -- and it was the debug
build that failed in the ubuntu-26.04 runs: the snappy error surfaced at
"Building x64-linux-dbg", before the release half was even attempted.
ResInsightMac passed -DVCPKG_BUILD_TYPE=release on the top-level CMake command
line, which has no effect on the ports vcpkg builds, so both macOS legs were
also building debug dependencies. Replace it with the triplet pair and add
x64-osx-release and arm64-osx-release, following the existing convention of
keeping a separate release triplet rather than folding VCPKG_BUILD_TYPE into
the shared overlay so local developer builds keep their debug dependencies.
The new triplets differ from x64-osx/arm64-osx only by
set(VCPKG_BUILD_TYPE release).
Verified that each of the seven cmake invocations using the vcpkg toolchain now
sets both triplet variables, that all four *-release triplets parse and resolve
to VCPKG_BUILD_TYPE=release, and that installing a port with x64-linux-release
builds only "x64-linux-release-rel" with no debug tree.
Also correct the overlay-ports path quoted in a Dockerfile.rhel8 comment, which
the previous commit narrowed to the thrift port directory.
Create .github/copilot-instructions.md as a minimal GitHub Copilot entry point, trim CLAUDE.md to a minimal pointer file, and move shared safety/output-expectation guidance into docs/agents/workflow.md. Also update the header/implementation-split rule in docs/agents/coding-style.md to allow short one-line bodies and short initializer lists inline in the header.
* Select RHEL8 vcpkg-configuration.json via CMake instead of renaming the tracked file
RHEL8 CI jobs previously ran 'cp vcpkg-configuration-rhel8.json vcpkg-configuration.json'
before configuring, temporarily overwriting the tracked default configuration
in the checkout. The vcpkg toolchain file only defaults VCPKG_MANIFEST_DIR to
CMAKE_SOURCE_DIR when it is not already defined, and reads it while processing
project(), so setting VCPKG_MANIFEST_DIR earlier -- before project() -- lets
vcpkg read a different vcpkg-configuration.json without ever touching the
tracked file.
Add a RESINSIGHT_VCPKG_PROFILE cache variable, implemented in the new
cmake/ResInsightVcpkgProfile.cmake (included from the root CMakeLists.txt
before project(), which is required for VCPKG_MANIFEST_DIR to take effect).
When set (e.g. to 'rhel8'), it copies vcpkg.json and
vcpkg-configuration-<profile>.json into a profile-specific directory under
the build tree and points VCPKG_MANIFEST_DIR there. The copy is regenerated on
every configure, so it can never drift from the root vcpkg.json.
overlay-ports/overlay-triplets entries (e.g. 'ThirdParty/vcpkg-overlay-ports')
are resolved by vcpkg relative to the directory vcpkg-configuration.json lives
in, so repo-relative 'ThirdParty/...' paths are rewritten to absolute paths
right after the copy is generated, keeping them valid from the new location.
Update the RHEL8 workflows and Dockerfile.rhel8 build-warmup stage to pass
-DRESINSIGHT_VCPKG_PROFILE=rhel8 instead of the cp step, and update
vcpkg-readme.md to describe the new mechanism.
* #14733 Use x64-linux-release vcpkg triplet explicitly in RHEL8 CI
The RHEL8 CI workflows and the Docker image's warmup/vcpkg-cache stages
did not set VCPKG_TARGET_TRIPLET/VCPKG_HOST_TRIPLET, so vcpkg fell back
to its plain x64-linux default triplet, which builds both debug and
release variants of every dependency even though the CI build is
Release-only. Set both to x64-linux-release consistently across the
image's vcpkg install, the warmup CMake configure, and the two
consuming workflows so the baked binary cache and the CI configure use
matching ABI hashes and skip the unused debug builds.
grpcio-tools 1.82.0+ (including its 1.82.0 pre-releases) bundles a
protoc that emits protobuf 7.35.x gencode, which no protobuf 6 runtime
can load. Pin grpcio-tools below that (excluding pre-releases via the
'.dev0' trick, since a plain '<1.82' bound already let a 1.82.0rc
release slip through once) and add a CI check that verifies the
generated *_pb2.py files stay within the protobuf floor declared in
pyproject.toml.
Only the load-bearing bounds are kept: protobuf's '>=6.33.5' floor
(must match the emitted gencode) and grpcio-tools' '<1.82.0.dev0'
ceiling. Non-load-bearing bounds (protobuf's '<8', grpcio-tools'
'>=1.81') were dropped since they don't change dependency resolution
or protect against anything the above doesn't already cover.
A full Windows build writes ~550 MB of buildcache entries, so the shared 500 MB limit was exceeded before the build finished. buildcache then evicted entries the same build still needed, and the cache never converged: rebuilding an unchanged tree against a cache written by that very tree hit only 44%, leaving the Windows leg at ~70 minutes while Linux, whose objects are half the size, finished in 83 seconds.
Move the limit into the matrix so Windows gets 1.5 GiB and Linux keeps 500 MB.
CMAKE_SYSTEM holds the host kernel release, which on the ubuntu-latest runner says nothing about the RHEL8 userland inside the container, so the el8 regex never matched. CPACK_SYSTEM_NAME is only set for Windows, so the fallback appended a bare underscore and the release asset ended up as ResInsight-2026.09.0_.tar.gz.
Let the caller state the distribution explicitly and skip the suffix entirely when neither name is known.
vcpkg only reads VCPKG_BUILD_TYPE from the triplet file, so the
-DVCPKG_BUILD_TYPE=release passed to the top-level CMake call never had any
effect and every port was built in both debug and release. On a cold cache
that is roughly half of an 85 minute vcpkg step.
Add release-only overlay triplets for x64-windows and x64-linux and select
them from the workflow matrix. They are separate triplets rather than an
override of the stock ones so local developer builds keep their debug
dependencies. VCPKG_HOST_TRIPLET is set alongside the target triplet,
otherwise the 12 host-tool ports (openssl and protobuf among them) would be
built a second time under the stock triplet.
The triplet is part of the vcpkg cache key since it changes every binary's
ABI hash.
Only save the buildcache from the default branch. GitHub scopes cache writes to the current ref, so a cache saved from a feature branch or PR is invisible to every other branch while still counting against the 10 GB per-repository quota and evicting the shared caches on the default branch.
Disable unity build for all configurations. Unity blobs invalidate on any change to the sources they bundle, which defeats buildcache reuse and fills the cache with objects that are unlikely to be hit again.
ResInsight-tests linked into the build root and copied its full runtime DLL
set there as a POST_BUILD step, the same pattern that made
extract-projectfile-versions race against the generated_classes.py edge. The
set is a superset of the one that failed, covering Qt6Gui, Qt6Widgets and the
rest, and nothing orders it against the code generation edge either. It fires
rarely only because copy_if_different compares content, so windeployqt having
already placed identical DLLs makes it a no-op. On a cold build where the copy
wins that race it genuinely writes.
Give the target its own RUNTIME_OUTPUT_DIRECTORY, and point the companion
PreBuildFileCopyTest target at the same directory so the ODB, OpenVDS and HDF5
runtime files stay next to the executable. That target runs before the link
creates the directory, so create it first.
Update the three workflows that run the test executable by path.
The copilot-setup-steps job ran before every Copilot task and spent up to
an hour on submodule checkout, Qt, vcpkg and a full build, which is wasted
work for documentation and other text-only tasks. Remove it so cloud tasks
start from a plain checkout.
The vcpkg ABI hash depends on more of the runner image than cl.exe: on
Windows every port's ABI includes the PowerShell version. Image
20260728 bumped PowerShell 7.6.3 to 7.6.4, which changed all 102 ABIs
while the cache key stayed fixed. The cache restored but vcpkg rejected
every archive, and the save step skipped because the key already
existed, so the stale entry never refreshed and every run rebuilt all
dependencies (98 min configure step).
The nightly image build has failed since 2026-07-23 with "failed to
solve: not_found" while exporting the BuildKit layer cache, because the
repository's GitHub Actions cache is at the 10 GB limit and entries are
evicted as fast as they are written (0% cache hit rate on restore).
Use a registry cache (ci-rhel8:buildcache in GHCR) instead, which has no
size cap, and exclude the buildcache tag from the daily image cleanup.
Make the cache effective across nightly rebuilds: key the vcpkg stage on
its actual inputs (vcpkg.json, the vcpkg configuration and the vcpkg
tool) with a direct manifest install instead of copying the entire build
context, and exclude .git from the Docker build context since its
internals differ between checkouts of the same commit and invalidated
'COPY . /src' on every run. Nightly builds now reuse the compiled vcpkg
ports from the layer cache and only recompile the ResInsight warmup
stage.
* #1009 macOS: add native Intel (x86_64) build alongside arm64
The macOS workflow only built on the arm64 runner (macos-15), producing
an Apple Silicon-only artifact that could not launch on Intel Macs.
Turn the single build job into a matrix that also builds natively on
GitHub's Intel runner (macos-15-intel), uploading a separate
ResInsight-macOS-x64 artifact next to ResInsight-macOS-arm64. All cache
keys (buildcache tool, buildcache contents, vcpkg) are qualified by
architecture so the two legs cache independently, and fail-fast is
disabled so a broken Intel leg never withholds the arm64 artifact.
The Intel leg uses a 13.3 deployment target: Apple's libc++ only ships
the <format> / std::to_chars(float) runtime symbols from macOS 13.3, and
the code (e.g. custom-surfio) uses std::format on floating-point values,
so a lower target fails to compile. 13.3 stays well below the runner's
macOS 15 SDK, keeping older Intel Macs supported.
release-draft.yml now downloads both macOS artifacts via a glob so each
architecture is attached to the draft release as its own zip.
Add a dedicated clazy-report workflow that configures the build to
generate compile_commands.json and runs clazy-standalone over
ApplicationLibCode and GrpcInterface as a report-only step.
Build clazy 1.15 from source against the installed clang/llvm-19 (the
packaged clazy is built against an older Clang that cannot parse
libstdc++-14's C++23 headers). Analysis runs one process per file
across all cores. The two highest-volume checks (range-loop-detach,
non-pod-global-static) are excluded to surface higher-signal Qt
findings, and ApplicationLibCode/UnitTests is skipped because gtest
headers are absent on this configure-only tree.
Add rhel8-package.yml that builds a RHEL8 install package from a tag
using the prebuilt RHEL8 CI container. It configures with an install
prefix, builds the install target, runs the CPack package target, and
uploads the resulting *.tar.gz as the ResInsight-RHEL8 artifact.
Wire the new workflow into release-draft.yml so the draft release waits
for the RHEL8 package run and attaches the *.tar.gz directly, alongside
the existing zipped platform artifacts.
The previous fix added VCToolsVersion to the Windows vcpkg cache key, but it is still too coarse. vcpkg keys each binary's ABI on a SHA-1 of the actual cl.exe binary content (ThirdParty/vcpkg/scripts/detect_compiler/CMakeLists.txt), not on the VCToolsVersion folder name. GitHub ships rebuilt cl.exe binaries under the same VCToolsVersion across runner image releases, so vcpkg's ABI hash changes while VCToolsVersion stays fixed. The restored binaries are then rejected and vcpkg rebuilds everything. Because the cache key did not change, the action skips saving the freshly built binaries, so the stale entry never refreshes and the rebuild loop persists across runs.
Observed on two dev runs with identical VCToolsVersion (14.44.35207), SDK and vcpkg SHA but different runner images (win22/20260616.203 vs win22/20260622.215): the first restored 102 packages from the binary cache, the second restored 0 and rebuilt all of them.
Hash cl.exe directly so the cache key tracks exactly what vcpkg tracks: a cl.exe change yields a new key, one cold rebuild, then a successful save under the new key, while image bumps that do not touch cl.exe keep restoring from cache.
The vcpkg binary cache was restored on every Windows run, but vcpkg rejected all binaries and rebuilt from source. vcpkg keys each binary by an ABI hash that includes the MSVC toolset version, which was not part of the cache key (only OS, compiler name, vcpkg submodule SHA and the vcpkg-configuration.json hash). When the runner image bumps MSVC, the restored binaries become ABI-incompatible and vcpkg rebuilds everything. Because the cache key stays unchanged, the action skips saving the freshly built binaries, so the stale entry can never refresh and the rebuild loop persists across runs.
Add the MSVC toolset version (VCToolsVersion, exported by the MSVC setup step) to the cache key on Windows. A toolset bump now yields a new key, producing one cold rebuild followed by a successful save under the new key, after which subsequent runs restore from cache.
The run-clang-tidy path regex matched generated moc/qrc files under build/
that are listed in compile_commands.json but not produced when the project is
only configured, not built. Exclude /build/ paths to remove the spurious
clang-diagnostic-error output.
On a tag push, wait for the Windows/Linux build (ResInsightWithCache.yml)
and the macOS build (ResInsightMac.yml) to finish, download their
application artifacts, zip them per platform, and create a draft GitHub
Release with the archives attached for maintainer review.
Replace the third-party celinekurpershoek/link-checker action with a
self-contained bash step that crawls the site sitemap and validates
page status, internal links, external links (with retry) and in-page
anchors against each target page's heading ids.
The script is inlined rather than referenced from a file because the
workflow also runs on gh-pages branch pushes, where the source tree is
not available.
Plain pip has no time-based cutoff, so route the workflow's package
installs through uv and set UV_EXCLUDE_NEWER to refuse releases
published within the last week as supply-chain hardening. Mirror the
policy in the rips pyproject for local uv installs.
Magne Sjaastad
dependabot[bot]