Replies: 2 comments 1 reply
-
We tried tod witch to mergequeues but it requires that every pr is rebased on master (so that it has the mergequeue in its ci configuration). We put off switching to mergequeues until that is fixed |
Beta Was this translation helpful? Give feedback.
-
I've not used GH Merge Queues personally, but does that matter? Can you enable them now so that new PRs will have it, then for old PRs they can rebase when they are ready to be merged? It's just sketchy to me to see a relatively large project have many open PRs and not have this strategy employed cause I've seen projects get funny compositional bugs without it. |
Beta Was this translation helpful? Give feedback.
-
I started using Helix recently and build it from the top of main every Monday morning. While looking at what interesting commits came about this past week I noticed that Helix seems to run its tests against each branch, rather than the merged branch. I think it is a good idea to do the latter, which is often called the "Not Rocket Science" rule. This can help catch bugs that running just PR CI will miss.
As a stop-gap using GitHub Merge Queues would work, but they do have some nice features that are missing. bors-ng/bors-ng is a good implementation but the public instance is being phased out since GH Merge Queues exist. Self-hosting is an option though. There is also Bors that rust-lang uses, but I wouldn't recommend that as it is old, has known bugs, and the codebase is a known pita to change. It is being rewritten though.
Beta Was this translation helpful? Give feedback.
All reactions