Almost all toolchains out there do a CI-first approach. There are clearly benefits for that, but maybe that’s not what one wants with their self-hosted solution for their OSS Projects?
Here I try to summarize some thoughts.
CI first is convenient, of course. Take github and Travis as an example. If a PR fails to build, one has not even to review it. If a change makes some tests fail, either the test suite has to be adapted or the code has to be fixed to get the test working again. But as long as things fail, a maintainer does not necessarily have to have a look.
The disadvantage is, of course, that resources need to be there to compile and test the code all the time. But that’s not that much of an issue, because hardware and energy is cheap and developer time is not.
Review keeps the number of compile- and test-runs low as only code gets tested which is basically agreed upon. Though, it increases the effort a maintainer has to invest into the project.
Review first is basically cheap. If you think of an OSS hobby project, that might be a good idea, especially if your limited funding keeps you from renting or buying good hardware where running hundreds or even thousands of compile jobs per month can be done at decent speed.
What I’d do
I’m thinking of this subject in the context of moving away from github with one of my projects (imag, of course. Because of my limited resources (the website and repository are hosted on Uberspace, which is perfect for that), I cannot run a lot of CI jobs. I don’t even known whether running CI jobs on this host is allowed at all. If not, I’d probably rent a server somewhere and if that is the case, I’d do CI-first and integrate that into the Uberspace-hosted site. That way I’d even be able to run more things I would like to run on a server for my personal needs. But if CI is allowed on Uberspace (I really have to ask them), I’d probably go for Review-first and invest the money I save into my Uberspace account.