Lets say I have the following app structure:

• Main API (e.g. Django/Laravel/.NET) (Git Repo: /main-api
• Main Frontend Webapp (e.g. in React/Angular): /main-frontend
• Admin Portal Webapp (e.g. in React/Angular): /main-admin

Given that I have a docker-compose set for the following services:

• mysql DB
• main-frontend app
• main-portal app
• main-api
• nginx

Lets say the CI/CD is arranged in a way such that, when either of the three repositories have any PRs merged on "master" branch, it will test and push a new build to the Docker Hub registry.

And, I have a fourth repo that basically uses following syntax on docker-compose.yml

...
...
api:
  image: <username>/main-api
main-frontend:
  image: <username>/main-frontend
...
...

How would the fourth repository figure out that there was a change on either main-api, main-frontend or main-admin repositories in Git and as such, a new docker image was pushed, and so to rebuild a new multi-containerized deployment and deploy it to a provider?

Given that if all the 3 repositories were structured into a single repository, it would be as easy as doing the entire CI/CD workflow on PRs merged on "master," but splitting repositories brings in challenges to perform an automatic CI/CD workflow. How would you solve this issue, or what does the industry practice in such a workflow because I'm sure no one uses one big repository instead of splitting the apps into three repositories.