CI: Add portability testing with passagemath's reusable GH Actions workflows

[mkoeppe]

https://github.com/passagemath/ is my pip-installable modularized fork of SageMath.

• I recently added Macaulay2 as a package to the distribution (building it from source using the cmake build system; see https://github.com/passagemath/passagemath/tree/main/build/pkgs/macaulay2)

In this PR, I propose to add a CI to Macaulay2 that reuses the infrastructure that I use in passagemath to ensure platform compatibility for building from source on a wide range on Linux, macOS platforms.

Preview of the workflow run: https://github.com/passagemath/M2/actions/workflows/ci-sage.yml

Right now, many tests are failing because my package build script (https://github.com/passagemath/passagemath/blob/main/build/pkgs/macaulay2/spkg-install.in) is not careful enough to make sure that M2 finds the right versions of dependencies. For example, an old version of FLINT is installed in the system, so the Sage distribution builds its own copy; but M2 insists on using the old version and fails.

See also:

• CI: Add integration testing with the Python interface passagemath-macaulay2 #3827

[mkoeppe]

Rebased to development

[mahrud]

To be honest, it seems wasteful to me to build M2 and all its packages from source in all of these platforms on every PR (each job takes >3hrs, and blocks other jobs because there is a maximum of 20 concurrently running jobs). Is there a reason not to simply install M2 from @d-torrance 's nightly PPA build for instance and run the Sage integration tests?

[mkoeppe]

When this workflow is run can be customized. It does not have to run on every PR.

[d-torrance]

Here's the link for the PPA: https://launchpad.net/~profzoom/+archive/ubuntu/macaulay2

It builds Macaulay2 for every supported Ubuntu release going back to 18.04 every day there's been an update to the development branch

[mkoeppe]

The parallelism of my workflow can also be customized.

[mkoeppe]

Here's the link for the PPA: https://launchpad.net/~profzoom/+archive/ubuntu/macaulay2

Thanks, I saw that in M2's CI scripts.

The principle of passagemath's packages is buildability from source on all supported platforms. Covering Ubuntu is great, but only one part of the story.

[mkoeppe]

Is there a reason not to simply install M2 from @d-torrance 's nightly PPA build for instance and run the Sage integration tests?

For the integration testing with the Sage library (the one job with passagemath-macaulay2), that might be a good idea, thanks.

[mahrud]

The principle of passagemath's packages is buildability from source on all supported platforms.

The majority of platforms that are listed are themselves not supported anymore; e.g. 20 jobs correspond to Fedora 30 through 40, minimal and standard, all of which are past their end of life now. Environmental concerns aside, I understand that using technology (e.g. docker, free compute time on GitHub, etc) we can test all of these integrations, but what is the added value over testing the integration on one platform and building a single docker image that is usable on any system that supports docker?

And again, the fact that this is literally blocking builds during the peak of our release cycle because a random macOS build has been stuck for 15 hours should be enough reason to question the added benefit:

Added: to be clear, I have no objection to running these tests on your fork for instance (well, I do have environmental concerns ...), but here I think there are plenty of bugs and improvements that could use volunteers time on a single platform, even before adding potential interoperability bugs coming from a zoo of platforms.

[mkoeppe]

You are discussing cost, not value. The cost is easily controlled by making a decision when to run it - namely sparingly.

[mkoeppe]

On homebrew I get

[macaulay2-git]   [spkg-install] CMake Error at /opt/homebrew/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:227 (message):
  [macaulay2-git]   [spkg-install]   Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)

Any hints?

[mkoeppe]

To simplify the discussion, I have narrowed the scope of this PR to just portability testing for build from source.

• For integration testing with the Python interface, see the new PR CI: Add integration testing with the Python interface passagemath-macaulay2 #3827

[mkoeppe]

I think there are plenty of bugs and improvements that could use volunteers time on a single platform, even before adding potential interoperability bugs coming from a zoo of platforms.

@mahrud Does the M2 project have a roadmap that would indicate when discussions of platform portability will be more appropriate or welcome than it appears to be now? Are we looking at a timeframe of a month, a year, a decade, ...? @mikestillman @DanGrayson @antonleykin

[mahrud]

Without speaking for others, I definitely value portability, which is why we have instructions for building and using M2 using docker, but I personally don't see the value of spending limited resources on testing M2 directly on each platform to the scale proposed in this PR.

With regards to #3827, which adds only one job, I think that would be valuable, but the build preview you linked failed and I thought you hadn't fixed it yet.

[mkoeppe]

Without speaking for others, I definitely value portability, which is why we have instructions for building and using M2 using docker

I'm sure that I don't need to explain in detail here why "use Docker" is not a one-size-fits-all solution. After all, in the M2 project there appears to be dedicated and high-quality work on homebrew packaging, Debian packaging, the bundling of source distributions of dependencies -- none of which would be necessary if it were.

[mkoeppe]

The majority of platforms that are listed are themselves not supported anymore; e.g. 20 jobs correspond to Fedora 30 through 40, minimal and standard, all of which are past their end of life now.

The centralized curation and maintenance of the list of platforms to test is part of the value of this reusable workflow. Since you ask about Fedora: I do keep these old versions of Fedora in the list to represent RHEL (for which I don't have direct tests) and the RPM jungle on users' systems.