Another example, for future reference, in case you ever decide to revisit this issue: intel-compiler-base. It takes 5 hours to build (really just to download and to re-compress all the files; I don't think anything gets built). I imagine I'm not the only one who is interested in testing with the Intel compiler.

To check if the extra packages need to be updated and update them, if necessary.

I'm not opposed to the latter, but then the question is how do I trigger a build job, when you update the archlinux image? Is there a hook to run my job, when core.sr.ht/archlinux.yml gets rebuilt? This is not unlike what we discussed yesterday, but in this case I don't control the dependency.

That's an interesting idea, but I'm not sure how such decisions are made within Arch. I know they keep track of the votes on AUR, but I don't know what happens beyond that. Are you familiar with their process?

It's also the case that one might want to test against packages that they are very unlikely to move to the community, such as the older versions of GCC, e.g., gcc7.

I'm running into a problem: I'd like to use a package from AUR that takes a long time to build. Specifically, it's MPICH, and building it takes around 20 minutes on builds.sr.ht.

I have several projects that depend on it, and it seems silly to rebuild it every time, for tests that take only a couple of minutes. I realize that I could maintain a binary package myself in a repository somewhere and add it to the build manifest, but that seems like it would be prone to errors.

The natural solution would be to have a sourcehut binary repo of common AUR packages that would be updated automatically, when the archlinux image gets rebuilt. Is this something you'd be interested in supporting? Or is there some other solution I'm missing?

This is somewhat related to #58, but with a simpler solution, I think.