#Lerna monorepo example

1 messages · Page 1 of 1 (latest)

lost imp
#

I'm looking for a sample pipeline implementation using Dagger which builds a Lerna monorepo. Any help is much appreciated 🙏

solar cape
lost imp
#

Thank you @solar cape , any reference to the Turbo repo implementation?

solar cape
verbal kindle
#

Thanks @solar cape!

Hey @lost imp thanks for your question. We don't have a lot of references for these use cases because monorepos are most common inside of companies and they don't normally have their pipelines open to the public.

toxic burrow
verbal kindle
#

Yeah for sure, I have not come accross Lerna yet, but if you get started we are happy to help with wherever you get stuck.

lost imp
#

I was able to get a basic setup with build, test and lint working. Not sure that’s the best way though. afk now will share the code snippet tomorrow

cinder kiln
#

I use a turborepo (at work, so yeah unfortunately can't directly share the impl) with multiple languages and the basics are just that I try to create functions that do individual things such as build a container, zip helm values, get the app and umbrella versions given the state of the repo, etc. Then for triggered pipelines I can chain multiple things together in another function.

To make those larger pipelines I just have a simple list of projects and dependencies (not project level dependencies, think databases and such) with a few config items that then get used for creating the pipelines above. I can simply loop/group over everything and do whatever is needed for that particular pipeline (version -> build -> publish -> charts -> tag is our basic CI, for example.)

As far as turbo/pnpm its largely used in the dagger context for three things: 1. getting folders to check for git changes (pnpm build --dry --filter=@repo/wahtever gets you a list of folders for a project to then use with a git command), so we only build when something has changed but I don't have to build up a dependency graph myself, 2. standard commands which are used by our docker targets (pnpm i, pnpm build, stuff like that), but which can be altered as needed per-project in project.json, and 3. pruning within docker to get only that project's files before building.