rust-cache VS bors-ng

In Github Actions we use swatinem/rust-cache. They have a pretty good explanation of what they are doing, and if that's not enough you can have a look at what the code is doing

Out of curiosity, does this play well with the Swatinem/rust-cache action? To improve CI cache performance, it's good practice to cache only dependencies' artifacts, and this action as such automatically cleans out the workspace local artifacts before populating the cache.

I've migrated to https://github.com/dtolnay/rust-toolchain for managing rustup, and https://github.com/Swatinem/rust-cache for caching

I'd also like to drop a recommendation to use https://github.com/Swatinem/rust-cache for caching cargo-related artifacts. I found it to be extremely pleasant to use and very easy to integrate into my CI pipelines.

There is an awesome github actions plugin that configures caching for `~/.cargo` and `target/`: https://github.com/Swatinem/rust-cache

Really cool! A few ideas: - cargo publish it! It'd be good to set the license, description, repository, and readme fields in Cargo.toml. - Your lib.rs looks good - clean & simply exporting types. - You could consider exporting Point/PointN at your library root (e.g. pub use them in lib.rs). If you expect a type will pretty much always be used, it's nice to export it at the root. It also makes those types easier to find on docs.rs. - There is a nifty github actions plugin that caches the crates.io registry, and your dependencies: https://github.com/Swatinem/rust-cache.

You can further protect main branch by using a rollup approach (see Bors for an example) where the pre-merge tests are run against the combination of those PRs currently proposed for merging, which limits the possibility that two PRs look OK but together break something.

Completely independent implementations of the same underlying concept, one of which was written pretty much just for the rust project, and the other was written as a more general tool and service.

Merge commit (via bors) because I hate squash merges.

Maybe the author does not know that there's https://bors.tech which is a publicly available Bors instance. There's absolutely no operational cost involved except for the initial setup.

Or images. On pages like https://bors.tech and https://foodpartners.us the "bloat" is all images. The images are bigger than they were in the 1990's because they look better, even if you don't think they communicate more "information" people may still want them.

According to the README, it bisects. It doesn't matter much for me, though - the batches in our case were never big.

https://github.com/bors-ng/bors-ng/blob/master/README.md#how...

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.