rust-lang
Package project with Nix (using `flake.nix` default Rust template)
Hi! :) I wonder what was the motivation for this PR? I'm not sure if we use Nix somewhere in infra (@Mark-Simulacrum ?), and it's probably not clear yet how will we actually run this bot.
We don't use nix anywhere in infra and don't expect to start to my knowledge.
Hey :) the motivation for this PR comes from here! If you don't want to be bothered with Nix expressions, I can let the work in my fork.
I see. I posted an answer on the Mastodon post - this project is not ready for usage yet, and it's not clear whether it will be useful to any other project outside of rust-lang. It currently doesn't implement any merge queue functionality, and maybe it won't implement that (if we find that GH merge queues are enough for our needs). So given that this bot is currently probably not very useful to other people/projects, and that we don't plan to use Nix, I think that it would be better to just keep this at your fork for now.
It currently doesn't implement any merge queue functionality, and maybe it won't implement that (if we find that GH merge queues are enough for our needs)
I personally does not like nor do I use the GitHub Merge Queue thing; and that's why I worked on my own version of bors (because I found this version a bit basic): https://github.com/TeamHarTex/HarTex/tree/0.5.1/bors (it is in a monorepo). I plan to have a publicly hosted instance in the distant future, but for now it is currently for my projects only. At some point I should extract the project from the monorepo indeed.
I believe I have basic queue functionality working (kind of), but yeah that is pretty much it.
Yeah after closer re-examination, merge queues probably won't be useful to us, because they waste CI resources too much with their overlapping rollups. Your bot looks really cool, and probably there will be a lot of overlap between it and this bot, I'll take a look if we can somehow use or build upon your implementation.
Yeah after closer re-examination, merge queues probably won't be useful to us, because they waste CI resources too much with their overlapping rollups. Your bot looks really cool, and probably there will be a lot of overlap between it and this bot, I'll take a look if we can somehow use or build upon your implementation.
I currently have try, try-, r+, r= and r- implemented (if I recall correctly), but I haven't implemented rollups yet.