How to set up for multiple microservice repos plus one react.js repo?

Hi all. I’m new to circleci and experimenting with it.

I was wondering how to set up circleci properly for a system made up of multiple (2) microservice repos and one react.js repo. Each repo has its own unit tests. There are some e2e tests for the whole system in a test environment where the builds of all three repos must be deployed. The source for the e2e tests are in yet another repo. In each release, the three repos (of application code) do not necessarily all have code changes, but I would like to run e2e tests when any repo has code changes. When more than one repos have code changes, I don’t want to run the e2e tests multiple times, meaning I want the e2e tests to be run only after the last deployment. What may be a good way to set up circleci for this?

Appreciate your suggestions.

CircleCI does not have any special features to aid in building a script to support such an environment, but it has a range of general tools that will allow it.

This allows you to write a config.yml script that can then in turn cause another script to be run. This allows you to dynamically create the second script or pull together runtime values that can be passed to the second script as parameters, which then allows better processing of those values.

While aimed at development environments that use a monorepo structure, this ORB allows for changes within a Repo to be found.

One complication you will have with just about all hosted CI systems is the fact that they are ephemeral and so must download the repos every time you execute a workflow. Depending on your code-based and repo platform this could add a delay to the whole process. CircleCI offers ways to store working file areas within its system

Workspaces allow data to be moved between jobs in a single workflow, while cache’s move data between jobs across different workflows.

If you are new to CircleCI, it may be best if you first create workflows that are just focused on each repo and get them working. You can then start to combine them with the tools listed above as you get to know the environment better. Doing it this way will also allow you to fully define what you need from the process - you could find that the best option is just to run all the different workflows without any additional integration and then run the tests if all the workflows completed.