Merge queues are, as the name implies, queues for pull requests/merges. They're kinda useless if your commit traffic is low (e.g. <10 per day), but become necessary once it grows past your daily CI time budget, roughly (which can happen on large monorepos).
As a very simple example, if your CI takes 10 minutes, your CI time budget is 6 merges per hour.
This is because if you merge two things in parallel without validating CI for the combined changes, your main branch could end up in a broken state.
Merge queues run CI for groups of PRs. If the group passes, all the PRs in the group land simultaneously. If it does not, the group is discarded while other group permutations are still running in parallel.
This way you can run more "sequential" CI validation runs than your CI time budget allows.
In our monorepo, we get a volume of 200-300 commits per day with CI SLO of 20 mins.
Without a queue, our best case scenario would be getting capped at ~72 commits per day before seeing regressions on main despite fully green CI (in real life, you'd see regressions a lot earlier though because throughput of PRs is spiky in nature)
> Merge queues run CI for groups of PRs. If the group passes, all the PRs in the group land simultaneously. If it does not, the group is discarded while other group permutations are still running in parallel.
That is a way of handling even higher volumes than GitHub is talking about, at the cost of a system that is a bit harder to think about. From the article:
With GitHub’s merge queue, a temporary branch is created that contains: the latest changes from the base branch, the changes from other pull requests already in the queue, and the changes from your pull request. CI then starts, with the expectation that all required status checks must pass before the branch (and the pull requests it represents) are merged.
The core principle is the same. How permutations are selected, of course, affects the performance and usability of the system.
Uber's[0] implementation, for example, does some more sophisticated speculation than just picking up whatever is sitting on the queue at the time.
Queues come with quirks, e.g. small PRs can get "blocked" behind a giant monorepo-wide codemod, for example. Naturally, one needs to consider the ROI of implementing techniques against aberrant cases vs their overall impact.
Collaborative coding is powerful. But to be at your team’s most optimized state, you need automated branch management that enables multiple developers to commit code on a daily basis, without frustration. This can happen if your team’s branch is busy with many team members onboarding the same commit onramp. This can be frustrating for your team, but, more importantly, it gets in the way of shipping velocity. We don’t want that journey for you!
This is why we built merge queue. We’ve reduced the tension between branch stability and velocity. Merge queue takes care of making sure your pull request is compatible with other changes ahead of it and alerting you if something goes wrong. The result: your team can focus on the good stuff—write, submit, and commit. No tool sprawls here. This flow is still in the same place with the enablement of a modified merge button because GitHub remains your one-stop-shop for an integrated, enterprise-ready platform with the industry’s best collaboration tools.
I read it yesterday and couldn't figure out exactly what they were talking about and upon re-reading, yeah, it's bad marketing copy.
The problem is probably whoever wrote the blog post (who is likely not even the named author, depending on how their marketing team does things) tried to add a lot of high-level stuff to make it make sense to them without really needing to understand the details, and then dolled it up with a bunch of useless vapid quotes from customers and what not, because that is what marketing people think matters. Maybe it does make sense to have mealy-mouthed corporate speak for the overall product, since some executive is probably deciding whether to use GitHub as a whole and they might care if a big company uses it. I don't know that it makes much sense for specific features like this, especially in a fairly technical product like GitHub.
It's totally unreadable. There's 5% meat in it almost at the very end, the rest is about selling the feature.
The problem is that if you have multiple branches going into the same (mono)-repo, then they might all pass a localized CI-check, but fail if they are all merged. This is because the branches have an interaction between them. It can lead to a stall in commits and because everything hinges on the repo, work is going to stall as well.
So you serialize the branches, and impose an order on them: [x_1, x_2, x_3, ...]. Now, when running CI on one of these, x_j say, you do so in a temporary branch containing every branch x_i with i < j. This will avoid a stall up to branch x_j, if you started to merge the branches in order. If CI fails on branch x_j, you remove it from the list (queue) of branches to be merged and continue.
I feel like since the Microsoft acquisition almost all their communications at all levels have gone from detailed info about features to fluff marketing pieces.
Beyond that, their API docs prior to the acquisition were some of the best in the industry, readable and concise. Now they are just a complicated mess.
> I feel like since the Microsoft acquisition almost all their communications at all levels have gone from detailed info about features to fluff marketing pieces.
Comms teams are really terrible in this regard. They insist on a singular 'voice', which means that every article is going to go through their review and get rewritten to their standard - that standard may involve removing technical content and instead making it more layman/ marketing friendly.
It's an incredible mistake that I see made everywhere after companies hit a certain size. It then becomes up to engineers to build their own engineering blog with less oversight and then guarding it from the comms teams, which most engineers aren't interested in doing.
The layman is, to a comms team, a manager, CISO, or some other mystery person I really couldn't explain to you. Yes, it's ridiculous and incorrect but that's my point.
I also have a hard time understanding what it really is.
What I think it is: instead of you trying to merge into the main branch, you try to merge into a branch where all pull requests before you are already merged in.
That way any pull request before you can't cause any merge conflicts, because they are already taken into account.
At least that's what I deduct from all the marketing fluff. Maybe I'm completely wrong.
Yes, but I find it hardly different from most articles today. Whether it's a blog post or a news story, an article will likely be a mediocre exercise in creative writing (with the intent to persuade) or a bunch of marketing waffle.
It automates the post-approval coordination stages of a PR for maintainers.
Let's say you're an open source maintainer with 3 pending Pull Requests to merge: [1, 2, 3]. Each of which is based off `main`, has passed CI and has been approved.
If you merge all 3 at the same time, there is a chance to break the build: Your CI is testing `main <- 2`, but you're merging `main <- 1 <- 2`. A common example would be when (1) is a user-supplied change, and (2) is a dependency/localisation change, which don't cause merge conflicts but they do break the build/tests.
To do this safely, you need to re-run CI on (2) after merging (1), which is currently a manual process: you need to know that (2) is next to be merged, then rebase/pull + rerun CI for (2).
(There used to be a manual step of 'merge once CI is passed' here, GitHub has recently improved this workflow to allow automation)
Merge queues fully automate the safe approach: it merges (1), runs CI on (2) which fails, then runs CI on (3), which passes and gets merged.
What happens if someone wants to merge when the queue is already running CI? Does it interrupt CI and start over, or does it run CI to the end and then kick CI off again with every new merge added to the queue since the last CI kickoff? Or does it merge on a successful CI and put together a new queue with those new waiting merges right after?
You know when you submit a PR at the same time as someone else, they both pass CI, and then both merge without editing conflicts, but then it turns out there were semantic conflicts and you accidentally broke `master`?
This fixes that. It removes the race condition that exists because of the gap between testing a branch and merging it.
The solution is very simple - have a queue of PRs and automatically test & merge them one at a time.
There are some optimisations you can do to speed things up a bit, e.g. testing a bundle of PRs all at once, but that's the gist of it.
It is basically essential on any repo that has a high rate of PRs. I'm surprised so many people here haven't heard of it.
Gitlab has the same feature but they annoyingly called it something worse - merge trains, and it's only in Gitlab Premium.
Yes, this set off all my 'gpt warning bells'. Anyone know the latest on automatic gpt detectors? Feels like it should be easy but last I checked they had a lot of false positives.
The problem is that you need to actually do training to detect AI text, and no one wants to spend money on that. The actual implementation is very easy:
1. get a corpus of real text
2. generate a corpus of AI text
3. train a model until it can tell the difference
The problem is step 2 is semi-expensive and step 3 is really expensive, so everyone is trying to shortcut the process, and of course it doesn't work.
Yes. But look at the bottom. There's an image with the PR review screen. There's one change:
* Normally, the big green button says "Merge pull request"
* Now, the big green button says "Merge when ready"
In a large project with lots of activity, a stampede of people pressing "Merge" at the same time will cause trouble. "Merge when ready" is supposed to solve this.
It seems to mean:
> "GH, please merge this, but take it slow. Re-run the tests a few extra times to be sure."
Here's in-depth details on how it works. [1] Basically, each PR gets put in its own branch with the main branch + all the PRs ahead of it merged in. After tests pass, they are merged in order.
Bors is also very similar to the Zuul CI system used for OpenStack. It has the equivalent of a merge queue (with additional support for cross repositories dependencies): https://zuul-ci.org/docs/zuul/latest/gating.html You can then have pull requests from different repositories all serialized in the same queue ensuring you don't break tests from any of the repositories participating.
Each PR on the queue is tested with whatever commits it would have were it merged to the target branch in queue order. So if the target branch already has commit A and commits B and C are in queue, commit D will be tested on its own temporary branch with commits A B C and D. If the tests for C fail, C is removed from the queue, and D is retested with just commits A B and D (because that's what would be on the target branch by the time it merges).
In what world is ranting about PR copy and saying someone should lose their job over quite literally doing what they were asked necessary?
Who, exactly, is it necessary for? The original commenter getting their rocks off on insulting someone else’s job? Others coming in and laughing at someone insulting someone else? Critically necessary.
It’s not like the original article author is going to come in, see this comment, and reflect deeply on themselves and their work.
I admit I was harboring a small hope that someone from GitHub / Microsoft might see the criticism here (not just mine) and that it might help reduce the frequency with which that sort of sales person tries to communicate with their market of software engineers. It was a bit unpleasant to suggest someone should lose their job. While they were presumably asked to write the piece, they were not asked to write it so tastelessly.
It is worth noting that according to a (Dutch language) article I read this morning, 90% of the listings that were removed had not been booked in the last year according to an Airbnb spokesperson.
> Het gaat vooral om slapende advertenties van woningen die al een tijd niet verhuurd werden.
> It mainly concerns sleeping listings of units that have not been rented out for a while.
The number of listings is also expected to increase again if the number of tourists bounces back up after Covid.
Of course, the linked article also mentions this, albeit without claims of it being large part of the number:
> This may concern ‘dormant’ advertisements of which the tenant is no longer active. For example, because the corona pandemic has shut down tourism in Amsterdam for a long time.
I was confused as well. I think (from some other comments) that the issue is that you can scroll to text that is specific to you and others might not have on their page (e.g. 'cancer' on some medical page) and then somehow gather from the requests that you scrolled there. It seems pretty hypothetical, but I can see the issue with forcing a scroll depending on what text is on the page, I guess.
Haskell type classes by default pick the implementation based on a single type variable in its signature, but it can occur in multiple positions (including the return type). A commonly used language extension (multi parameter type classes) extends this to an arbitrary number of type variables.
The thing is, you're focusing on when you've detected that there is an issue (a crash). A lot of the issues with NULL are the fact that you can't easily detect if beforehand. It's not indicated in the types, or the syntax. That means that it's incredibly easy for a NULL issue to sneak into an uncommon branch or scenario, only to be hit in production.
To add to that, there's also the fact that any user of any ISP that throttles/blocks torrent traffic is probably going to have the same experience. Plus the fact that there's at least two people I know whose ISPs actually cut users' down speed by double of any up speed (in order to "passively" cut down torrenting without actually restricting it). So PeerTube becomes less a YouTube replacement and more an interesting implementation of streaming video via Bittorrent (which some clients already support).
I aliased 'g' to 'git'. Combined with git aliases ('st' for 'status' etc) this is almost as short but doesn't steal all the short names from your shell. So instead of 'gs' you have 'g st'. Upside is you save two letters even on uncommon git commands :)
