It is common for developers to treat Continuous Integration as "a build server", but it is more than that. Continuous integration optimises team flow by encouraging them team to regularly rendezvous via the main development branch.
My general rule of thumb is that every developer should commit to the repository every day. In practice it's often useful if developers commit more frequently than that.
Martin Fowler
Therefore, Pull Requests can hinder Continuous Integration by destabilising the overall team flow. Team co-ordination several times a day is a form of Fast feedback improves quality, as The quality of conversations drives the quality of the product. When conflicts arise, they're fixed on a small turnaround through team communication.
Continuous integration as a development practice therefore encourages working in small increments that are easy to integrate (Small increments act as save points), or revert. Implementation techniques arise from this, such as:
Models which hinder Continuous Integration, such as the Pull Request model, will slow down teams (Pull Requests can hinder Continuous Integration).
One way to do so is to use source control tooling as the 'golden source' of information; where the documentation can be change-controlled (thus preserving history), but also utilise the power of Continuous Integration tooling to generate documentation based on the current state of the system.
A core quality of a microfrontend architecture is that the subsystems should not be dependent upon one another, therefore able to practice Continuous Integration with autonomy in their subdomain.
Naturally, this means each team is free to practice their own isolated Continuous Integration of their code.
Continuous Integration is often misunderstood as being a build server, but it's actually the practice.
Continuous Integration is a team co-ordination effort that allows for teams to work collaboratively and enable the delivery of value