The implication to the name monorepo is that there exists just one – everything is contained within it. But in Getting Rid of Old Code, I mentioned that 45 repositories would make it into the monorepo. This means 15 repositories did not make the cut. If we’re aiming for a monorepo, why were these repositories excluded?
Our primary objective is to gather together all of the code, infrastructure, and documentation related to our own development efforts into a single place. This is what is represented by the 45 repositories that were merged into a single repo.
One category that was excluded from the monorepo was forks for dependencies. We have forked and modified some of the external dependencies we rely on, such as eyalroz/printf and JuliaMath/openlibm. These could be merged into the monorepo, but managing these projects outside of the monorepo makes it easier for us to stay in sync with changes made in the original repository. Furthermore, these projects will still be present in the monorepo via Meson’s subproject system.
- During the initial build step, each dependency is checked out and placed into the
subprojects/folder. - We can commit and push to these projects without leaving the monorepo.
- Incorporating these projects via the dependency system makes it trivial for us to revert to the original dependency repository when necessary.
We also have some repositories that represent forks of applications, such as the git and git-filter-repo forks we created to support preserving and restoring commit signatures. We don’t want to pollute our own project history with the commits from this projects – especially large ones like git. We also hope that we can get our changes merged upstream so we can eventually delete the forks and move back to an official release.
The remaining repositories represent independent efforts that don’t fall within the realm of our regular development work.
- We have a repository that stores source code for our courses.
- This, in itself, can be considered its own monorepo, as we keep all the exercises and solutions for every course in one repository.
- The medtronic-pb560 repository is used for analysis, not development (our analysis can be found in the Open Ventilator Design Review course). We don’t need to pollute the monorepo with code that we will never actually use.
- Our websites (https://embeddedartistry.com/ and https://embeddedartistryconsulting.com/) each have a repository that contains all of the published content.
- We never interact with these repositories directly.
- Instead, we added a “publish” command to our writing tool that pushes content updates to the website using these repositories.
We will also exclude client projects from the monorepo. This isn’t our code, and these repositories are typically deleted from our organization after the project is completed.
So, while we still have multiple repositories, we can safely reduce our focus to only a handful of repositories:
- All of our own development work happens within the monorepo – including work on forks of external dependencies.
- Changes to course-related source code will happen within the course-code repository.
- Repositories for client work, forked applications, and forked dependencies will come and go as needed.
References
- Getting Rid of Old Code – a highly recommended step, whether or not you are planning to move to a monorepo strategy