Comment by frankjr
2 years ago
I wonder if something like that should be built on top of GitLab now that you have migrated to it. GitLab CI supports multiple runners for a single job, so the workflow might be that you merge a merge request which modifies PKGBUILD/.SRCINFO, the CI picks it up and based on labels/tags dispatches it to different runners running possibly on a completely different architecture for building. The runners then send the artifacts back and the job publishes them. The nice thing about this is that most of the parts are already there handled by GitLab itself, you just have to draw the rest of the owl.
This doesn't help at all as you need to coordinate so-name rebuilds across multiple architectures. This implies you need to some way to orchestrate a staging repository and have building do rebuilds towards this repo interactively until all issues are solved.
Retrofitting this ontop of gitlab sounds painfull. I don't even know if we would like to be that tied to a singular forge.