Alternative approach to the current containers with compiled packages...

[fingolfin]

Right now, we try to use a container which contains GAP and "all" packages that are "currently" in the distro. Well, were in the distro when that container was last updated. So we need to update it frequently, creating a lot of churn.

So how about this instead (which is arguably closer to what we used to do):

• have a base container with GAP, gcc, and as many externalpackage dependencies as possible; essentially that would be https://github.com/gap-system/gap-docker-base plus GAP; resp. https://github.com/gap-system/gap-docker-base minus BuildPackage.sh and some extras
• in the CI, have one job which fetches the latest package distro
• then build "all packages" -- it should be reasonably fast (the slowest part of building all packages for me right now is building NormalizInterface, because it builds Normaliz; but if we set up things right, it shouldn't have to do this, because Normaliz will be installed already in the container)
  • either build them all in one job, and upload the resulting files as an artifact (I'd try to only upload the bin directories, not the rest of the packages, as that requires far less space). possibly the caching system would also help
  • or perhaps this can simply be done as part of the CI tests for each individual package (then we could even restrict to just compiling what is needed for that package)

The advantage of this would be that we'd be much more agile; we could then indeed easily test individual commits of the package-distro, if we wanted to.

[wilfwilson]

I'll give it some more thought, but if this is technically feasible, then I think that would be fine.

I agree that the aim should be for the scripts/Workflows in this repository to eventually be merged with the package distribution repository; this makes sense. The purpose of this repository is mostly to test packages in the package distribution (although it's also to test GAP - i.e. has a commit to GAP master broken a package?), so it should be very easy to test against arbitrary versions of the package distribution (or its pull requests).