Our great sponsors
-
As with many words, monorepos can mean different things to different people.
Some people use it for a repo where a single product is developed and typically deployed/published together, but happens to be distributed through separate packages. The Babel repository would be one example of this: https://github.com/babel/babel
-
bazel is a very powerful tool due to it's design builds are fully cacheable und you can bring your own toolchain - so it's good for having reproducible builds without any system dependencies - here is an complete example: https://github.com/drakery3d/fullbazel - it's flexible and powerful but also complicated and it's probably difficult to convince your team/org to adopt it.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
In a perfect world, you can scale CI indefinitely. However, I don't think it's a simple as that. As mentioned in the post, even with a hermetic build system your CI times become entwined with your dependency graph, no matter if you're able to shard it over remote executors or not.
The block you've quoted specifically mentions gating _merges_. I still think its prudent to run ~all tests after merge, with automatic reverts if tests start failing. I really want to make sure that people think of CI, merges, and deploys as pieces of a larger puzzle and not a monolith.
I updated the language around this in [0], hope that makes it clearer as to my intention.
[0]: https://github.com/felixmulder/felixmulder.github.io/commit/...