Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Sounds like they settled on the bors model of a batching merge queue. Gitlab's merge trains instead speculatively run all of the merges at once which gives more precise data at a higher cost and longer time, if your number of parallel runners is limited.
If I take Github as an example with their cache action. It is caching it in the repository, so each following action runner has the cache passed to it. I didn't find the perfect formula yet, but it's worth a try.
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a more popular project.
Related posts
- Bors: Elixir GitHub bot that prevents merge skew / semantic merge conflicts
- Bors: Elixir GitHub bot that prevents merge skew / semantic merge conflicts
- How do you WORK WITH testing teams?
- Merge Commit, Squash, or Rebase: how do you close Pull Requests on GitHub?
- Whatâs a bors, and why (donât) you want it?