DEB packaging in Github Actions

[simonlegrand]

Here is a new workflow release_deb.yml to build .deb packages of FreeFEM. It works as follow:

1. triggered by v*.* tags
2. calls the full_openmpi.yml workflow to build FreeFEM on ubuntu 22.04 and 24.04
3. gets the build artifacts to package both version in .deb format
4. Create the Github release and upload assets

Might be clearer with a small flowchart:

flowchart TD
    subgraph CI:
    CI@{ shape: lin-rect, label: "Push master/develop\n PR develop"} --> F(full_openmpi.yml)
    end
    subgraph Release:
    Release@{ shape: lin-rect, label: "tag v*.*"} --> |1| R(release_deb.yml)
    R --> |2|F
    F --> |3 - Build artifacts| R
    end
    R --> |4|DEB@{ shape: stadium, label: "FreeFEM-...-ubuntu-....deb" }

Loading

The full_openmpi.yml workflow has been modified to be able to be called by the release_deb.yml workflow and be given the following arguments:

• build_types (default to both debug and release)
• versions (default to both 22.04 and 24.04)
• skip_check (to avoid repeating the make check when releasing)
• upload_build_artifacts (mandatory to allow release_deb workflow to access the build tree)

The schedule is tight so I didn't create a meta 'release.yml' workflow that calls release_deb.yml, but that's definitely the idea for the future.

[prj-]

Why use Open MPI instead of letting PETSc compile MPICH? What if users install the .deb but have already MPICH installed?

[simonlegrand]

We could do that, but in my opinion it's better to leave MPI as an external dependency since the user could have other softwares compiled against OpenMPI or MPICH provided by the distribution. The ideal case would be to provide both MPICH and OpenMPI versions of FreeFEM (like hdf5 for instance), but with MPI as an external dependency. I can try that if you want.

[prj-]

The ideal case would be to provide both MPICH and OpenMPI

No, that's a nightmare to maintain, you have two different MPI implementations, with possibility different versions between 22.04 and 24.04. Again, I'm really not sold on the idea of relying on an apt-installed MPI implementation, see, e.g., a very recent bug report https://community.freefem.org/t/freefem-compilation/4150.

[simonlegrand]

In 87002f3, I have added an input parameter to full_mpich.yml to deactivate the macos jobs when called from release_deb.yml.
But I was thinking about spliting it into two differents workflows:

• full_mpich_ubuntu.yml
• full_mpich_macos.yml

Beyond limiting the number of input parameters, it would allow to have more refined badges (one badge/workflow). What do you think?

[simonlegrand]

I rebased the branch on develop. I pushed a tag v4.16-test to trigger the packaging, but it isn't propagated to this PR. The pipeline associated is run here and the release is visible in my fork here