This job seems redundant now, since we already have three jobs compiling
with Clang ("ubuntu:production-libc++",
"ubuntu:production-arm64-libc++", and "ubuntu:production-dbg-clang") and
one job that implicitly compiles without libpoly ("ubuntu:safe-mode").
This ensures compatibility for statically linking cvc5 with Lean
binaries on Windows for Lean versions 4.20 and above, as required by the
lean-cvc5 project.
This PR moves the cross-compilation CI jobs out of the main workflow and
into a nightly scheduled one. Since native builds now cover all
supported platforms, cross-compilation testing is less critical. This
change streamlines CI and reduces cache contention.
The new artifacts simplify integrating the cvc5 library into
[lean-cvc5](https://github.com/abdoo8080/lean-cvc5), which requires cvc5
to be compiled with libc++.
This PR replaces the MSYS2 MINGW64 environment with the CLANG64
environment for compiling cvc5 natively on Windows x86_64. The main
difference between the two is that MINGW64 uses GCC and links against
libstdc++ and the MSVCRT runtime, whereas CLANG64 uses Clang and links
against libc++ and the UCRT runtime (see the MSYS2 [environment
documentation](https://www.msys2.org/docs/environments/) for details).
This ensures compatibility for statically linking cvc5 with Lean
binaries that use libc++ on Windows x86_64, thus facilitating the
integration of cvc5 into
[lean-cvc5](https://github.com/abdoo8080/lean-cvc5).
---------
Co-authored-by: Abdalrhman Mohamed <abdoo8080@outlook.com>
The new version of the `cibuildwheel` action uses the final CPython
3.14.0 release to build wheels for that version, rather than a release
candidate, although using the candidate release should still produce
ABI-compatible wheels.
This prevents workflow runs on the `main` branch in forks from failing.
Additionally, this PR passes the `--batch-mode` option when deploying to
Maven Central to reduce the verbose feedback that is normally reported
in interactive mode.
This PR builds and stores the JNI library in a directory structured
according to the OS and CPU architecture. This allows a single JAR to
contain native JNI libraries for multiple OSes and CPU architectures
simultaneously, and prevents file collisions when multiple JARs
containing a native JNI library for the same OS but different
architectures are added to the classpath.
The macOS 13 runner images are
[deprecated](https://github.com/actions/runner-images/issues/13046) and
will no longer be supported after December 4.
In order to make the Python wheels work on Intel macOS 15, it was
necessary to use repairwheel 0.3.2, which includes a bug fix related to
the `__LINKEDIT` segment size.
This PR adds support for CPython 3.14 (scheduled for release on
2025-10-07) and drops support for CPython 3.7 and PyPy 3.7. It continues
to use the `manylinux2014` image to maintain compatibility with glibc >=
2.17 and older Linux distributions such as Amazon Linux 2.
This adds `stable` as a build type, which is similar to `safe` but
permits incomplete proofs in regressions and the use of regular options
with `no-support:` fields.
This PR centralizes the creation of release pages in a single job, which
runs at the beginning of the workflow, using its own concurrency group
to prevent race conditions from happening. It also removes the
dependency on PyGithub and simplifies GitHub token handling.
This PR changes the GH job used to build the documentation from
`ubuntu:safe-mode` to `ubuntu:production-dbg`. The previous
configuration was failing to generate some example outputs for the files
specified in `base_options.toml` because certain options are not
compatible with `safe-mode`.
This PR updates the current code to address two issues:
1. CI sometimes spuriously fails when one job tries to remove an asset
marked for deletion, but another job has already deleted it.
2. The code uses a hard-coded value and a counter to enforce that at
most two builds per platform are kept. Now that the number and variety
of artifacts has grown, this simple approach no longer guarantees that
the correct set of artifacts is deleted.
This PR resolves the issues above by:
- Running the cleanup code in a single job after all jobs that build and
upload artifacts have finished. Moreover, the new job uses a GitHub
concurrency group to ensure that only one cleanup job runs at a time
across concurrent workflows.
- Grouping assets by prefix and date to ensure that only the two most
recent artifacts for each prefix and the newest asset for each date are
kept.
The new code preserves the previous behavior of deleting any asset older
than 7 days. It also removes the dependency on PyGithub, so no
additional installation is required in the new job.
The `setup-cmake` GitHub action has been a bit flaky lately. Since
testing with an old CMake version is not critical, this change allows
the process to continue even if it fails.
This PR raises the quality standard for the cvc5 Java API documentation
by treating all warnings reported by Javadoc (in Java 21) as errors and
by addressing the remaining warnings in the source code. Since newer
versions of Javadoc catch more issues than older ones, this PR uses the
current Long-Term Support (LTS) release of Java (version 21) to generate
the documentation. However, it continues to use Java 8 in the workflow
jobs that build the JAR files for releases in order to maintain backward
compatibility with the older Java version.
---------
Co-authored-by: Aina Niemetz <aina.niemetz@gmail.com>
We use a "latest" release that is updated with the assets of the latest
commit on push to main. This "latest" release has been previously
manually tagged as prerelease. This commit ensures that it is
automatically tagged as prerelease if we ever delete the release and
create it afresh.
