Update ci to update windows and ubuntu runners

[jhmgoossens]

See also COIN-OR-OptimizationSuite Issue 32 and Issue 33:

1. Remove Windows Server 2019 runner images for Actions are being deprecated in June 2025.
2. Add tests for the new Windows Server 2025 which was released Nov 2024.
3. Similarly, remove deprecated Ubuntu 20.04 and add new Ubuntu 24.04

These changes are done for linux-ci, windows-ci (using coinbrew) and windows-msvs-ci (using Visual Studio solutions) workflows.

[jhmgoossens]

The build using arch: x86_64 using mingw64 on windows-2025 fails with a familiar error from CoinUtils PR 245 and CoinUtils PR 246.

D:/a/CoinUtils/CoinUtils/CoinUtils/src/CoinRational.hpp:17:3: error: 'int64_t' does not name a type
   17 |   int64_t getDenominator() { return denominator_; }
      |   ^~~~~~~

Notably, this commit -- thanks @tkralphs -- fixed this for windows-2022 runners.
But now the error is back for PR 249 only on windows-2025 runners, not windows-2022.

Any idea how to this could be failing only for windows-2025 runners for arch: x86_64 using mingw64?

[svigerske]

It can happen that a missing explicit include of a header becomes a problem only after updates to standard header files.

Since CoinRational.hpp uses int64_t, it should be the one that includes cstdint. That change is now on master with #250.

[tkralphs]

The OS name is specific to Github Actions and I guess it's not really indicating anything about the platform or toolchain. The w64 indicated 64-bit, now the string doesn't really have a meaning aside from just that this is windows. I guess assuming 64-bit across the board is reasonable, but then should we just maybe have win here? Or we could just leave it as w64?

[jhmgoossens]

Indeed, I had to add the OS to get unique artefact names, not because of toolchain differences and certainly not to give the impression that one package is for WS 2022 and the other for WS 2025. For regular ci builds I guess this is not such a problem, but this shouldn’t make it into different release artefacts (IMO).
Does this make it too difficult for the release packages?
If so, I can just reduce the matrix and keep only one toolchain/debug combo, not duplicated per OS. I like to keep duplicate combinations per OS exactly to catch unexpected issues like the cstdint/stdint identified for WS2025.
Sure, I will change w64 to win.

[tkralphs]

Yes, I would keep only one toolchain/debug combo.

[jhmgoossens]

The artefact name changes have been reverted (no more OS name), and the build matrix was reduced to ensure the artefact names are still unique. In the revert, I left the old "w64" so didn't change it to "win".

For the "msvc" builds, the Visual Studio version is used in the yml to build the artefact name (package name). For windows-2019, this was VS 2019 (v16), but for windows-2022 and also windows-2025 this is VS 2022 (v17). Therefore, 2022 and 2025 builds with "arch: msvc" will both come out "msvc17". To ensure uniqueness of these artefact names while keeping both 2022 and 2025 builds, I made the 2022 msvc a "debug: true" build.

Same changes pushed to Cbc PR 728.

Once we're happy with the outcome I'll push the same to all other projects. Comments?

[tkralphs]

Everything looks good, did you say you wanted to open all the PRs and test before merging any of them?

[jhmgoossens]

Everything looks good, did you say you wanted to open all the PRs and test before merging any of them?

Yes, that was the idea..
See comment on OptimizationSuite Issue 32.