Our mission at Semaphore is to empower engineers to ship excellent products by providing them with a state-of-the-art CI/CD experience. We’re excited to announce that Semaphore is the only CI/CD solution that provides powerful out-of-the-box support for monorepo projects.
A while back, our team introduced the first step in supporting monorepo: the change_in function, which made it possible for users to speed up their pipelines by skipping code that hasn’t changed. After hearing back from our users, we’re launching a new set of monorepo features in Semaphore.
Monorepos offer many benefits for engineering teams, but until now, setting one up was needlessly traumatic. Since we use a monorepo ourselves, we understood the pain of setting up a functional CI/CD pipeline. It goes without saying that we were very motivated in making the experience of configuring such a project on Semaphore a seamless process.Damjan Becirovic, Software Engineer at Semaphore
What is monorepo?
A monorepo is a version-controlled code repository that holds many projects. While these may be related, they are often logically independent and run by different teams.
What’s new and why did we add it in the first place?
Over the last few years, we came across many users that rely on monorepo setups in their organizations. To enable them to use our product, we introduced the
change_in function for Semaphore workflows. Based on the feedback we received, it became clear that there are several key qualities we need to provide: reliability, robustness, simple configuration, and easy troubleshooting.
As a result, we have developed the following improvements:
- Initialization step – Runs at the start of each monorepo pipeline and compiles the workflow, ensuring that misconfigurations are detected before any job starts.
- UI indicator – A new UI element shows the initialization log, making troubleshooting fast and easy.
- Exclude parameter – A new option in
change_inadds the ability to define which folders or files to skip.
- Glob pattern support –
change_inconditions have been further extended to allow the use of wildcards.
- Improved stability – All compilation errors coming from edge cases were eliminated, making these features more reliable.
Who is it for?
Monorepo users will benefit from the improved
change_in function and the new UI elements. Take BlueLabs as an example. They were able to reduce build times from 17 minutes to 4 with a combination of change detection and some clever caching strategies — that’s 76% faster.
“We decided for monorepo because we wanted to build as much code as possible across different projects while avoiding broken releases due to incompatible versions.”Pietro Grandi, Engineering Lead of Client Team at BlueLabs
If your organization has a monorepo and isn’t using these features, this is a great time to check them out.
Users with multirepo setups can benefit from the new features too:
- Custom workflows for changes on specific files – Use
change_inin combination with glob patterns to define jobs that will run only when certain files change.
- Skip unnecessary checks – No need to run that whole test block when a README.md changes. Save some CI time by using exclude option to define files and folders you want to ignore.
- Improve your deployment strategy – Combine auto_promote and change_in to make your deployment rules even smarter.
How to start using it?
Setting up a monorepo project is as easy as defining a run/skip condition. To get you started you can check out this docs page that explains the basics.
If you’re more of a hands-on type, check out this already-configured demo. Feel free to fork and play with it.