3 ms·

How do monorepos work with something like gitlab or github, which expect a CI file in the repo root? My workplace has dozens of repos, and they all have separa

How do monorepos work with something like gitlab or github, which expect a CI file in the repo root? My workplace has dozens of repos, and they all have separate CI needs and test suites. Trying to shoehorn them all into a single set of CI pipelines would be very difficult, even with the include and parent-child pipeline features.

shagie 4y ago
The CI file can specify what triggers different workflows. https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#accessing-and-using-event-properties https://docs.github.com/en/actions/using-workflows/triggerin... on: pull_request: types: - opened paths: - '.github/workflows/**' - '.github/CODEOWNERS' - 'package*.json' That triggers when those files change. The "get them all to run in a single repo" is the challenge of the monorepo. The trade off is "if you change a common library, how do you trigger the test suites in all of the downstream repos to run with the new common library and verify that they still work?" With a monorepo, that second part is solved for you... at the cost of needing to solve the problem that you're asking about.
atomicfiredoll 4y ago
I have the most expense with Nx and can only speak to that. Nx projects are tied together with a dependency graph. The workflow/pipeline replaces something like "npm build" with with "nx affected --target=build --base=main". Nx compares the code to the base branch, identifies the leaves of the tree (projects) affected by the code change, and runs the specified task for each project. Each project can specify what that task (technically the "target") means in it's own context by directing it to run a specific "executor." For some projects, "build" may run a Weback executor, others may map it to run a Vite executor. Edit: To summarize, if you change something deep down in the tree like a design token, you can run the "test" and "build" tasks for everything affected by that change to make sure none of your apps break. If those projects are SPAs built in different frameworks, each can map the task to run the framework specific "test" or "build" executor. Now you have automatic assurance that all your apps still work. If that sounds like a lot for the CI to do, that's where distributed caching the of task results come in.
sanderjd 4y ago
> dozens of repos, and they all have separate CI needs and test suites Standardizing all of this is one of the advantages.

shagie 4y ago

The CI file can specify what triggers different workflows. https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#accessing-and-using-event-properties https://docs.github.com/en/actions/using-workflows/triggerin... on: pull_request: types: - opened paths: - '.github/workflows/**' - '.github/CODEOWNERS' - 'package*.json' That triggers when those files change. The "get them all to run in a single repo" is the challenge of the monorepo. The trade off is "if you change a common library, how do you trigger the test suites in all of the downstream repos to run with the new common library and verify that they still work?" With a monorepo, that second part is solved for you... at the cost of needing to solve the problem that you're asking about.

atomicfiredoll 4y ago

I have the most expense with Nx and can only speak to that. Nx projects are tied together with a dependency graph. The workflow/pipeline replaces something like "npm build" with with "nx affected --target=build --base=main". Nx compares the code to the base branch, identifies the leaves of the tree (projects) affected by the code change, and runs the specified task for each project. Each project can specify what that task (technically the "target") means in it's own context by directing it to run a specific "executor." For some projects, "build" may run a Weback executor, others may map it to run a Vite executor. Edit: To summarize, if you change something deep down in the tree like a design token, you can run the "test" and "build" tasks for everything affected by that change to make sure none of your apps break. If those projects are SPAs built in different frameworks, each can map the task to run the framework specific "test" or "build" executor. Now you have automatic assurance that all your apps still work. If that sounds like a lot for the CI to do, that's where distributed caching the of task results come in.

sanderjd 4y ago

> dozens of repos, and they all have separate CI needs and test suites Standardizing all of this is one of the advantages.