This officially made Github my go-to recommendation for forge over Gitlab.
For years, Gitlab was ahead: CI for free, Merge Train, etc… But from around the time they were teasing IPO until now, they have fallen way far behind. This gave room for Github to play catch up, and under Microsoft they sure did it fast:
Ship Github Action and became huge
Ship Codespace which Gitlab still struggles to get a POC out to compete
Ship Code Search, while Gitlab struggles to copy from Sourcegraph
Ship Copilot, … Gitlab has nothing.
Just yesterday, I still have to remind Gitlab to focus on completing their Merge Train features https://gitlab.com/groups/gitlab-org/-/epics/4911… but no, that’s +2 years old epic is now pushed back again because they want to try to build some green field projects.
Meanwhile, Github has been consistently delivering features for the last few years and did not get distracted by “Kubernetes Firewall” or “Serverless”. They win.
We use Mergify as a bot to babysit the GitHub merge train at my job. It can rebase, and we have set it to always rebase before merge, but it can’t autosquash your fixups yet, so that’s still manual labor. It also sort of supports dependent PRs, but GitHub being GitHub, it doesn’t quite work.
The world is stubbornly not perfect yet. Except, I’ve used Gerrit, which was very different and very right if you like the rebase workflow. You don’t need fixup commits, because you can just force push and it shows what you actually did different each time, or if it was a trivial rebase.
Yay! This has been one of my most wished-for features for GitHub for years. Hopefully next they’ll get to tracking comments across updates to PRs, allow stackable PRs, and support *BSD in Actions, and then I will have nothing left to complain about.
While it’s not an official GitHub feature, you can use https://github.com/vmactions to run BSDs and Solaris on GitHub Actions (using VirtualBox on macOS).
I might try it again soon. I’ve move recently been trying this one. With a third-party reimplementation of the actions runner, I’ve managed to self-host some FreeBSD VMs as action runners, but I’d love to see this become officially supported, especially with GitHub-hosted runners.
I ended up switching back to vmactions. The xhyve implementation is somewhat flaky and we had jobs just wait for timeout before exiting, even though the tests pass fine in VirtualBox.
Well, I sure hope they have ironed out more of the bugs than I have seen. My last organization used this in the private beta and it was … well, fickle. Of course, it’s been a whole month since I have used it last, so it very well could have changed.
At one point, we got a refund of 2/3 of our minutes because of all of the duplicated CI runs. We also saw that when the head of the queue merged and changed the main SHA, it would then stop all subsequent jobs and restart them with the new SHA (even though the whole point of the queue is that it should already be applied :shrug:). Early on we had to actually force-stop all non-head-of-the-queue jobs because we would both run out of parallelization and the jobs would restart anyways. We would constantly see the queue get “stuck” and have to stop all of the jobs and then requeue (AKA hit the green merge button in the PR) all of the branches. It was nearly a full-time job babysitting the MQ.
In theory, though, this is a fantastic way to not force everyone into “Branch must be up to date with main before merge” but still get all of the benefits.
This is how GitHub has deployed itself for years, using a bunch of internal tooling. Nice to see they’ve finally built it in and made it available to others.
Sad to see this only available for enterprise orgs. While a lot of non enterprise orgs probably don’t need something like this, it’s still useful at smaller scales but not a whole $17/user/month more useful.
This officially made Github my go-to recommendation for forge over Gitlab.
For years, Gitlab was ahead: CI for free, Merge Train, etc… But from around the time they were teasing IPO until now, they have fallen way far behind. This gave room for Github to play catch up, and under Microsoft they sure did it fast:
Just yesterday, I still have to remind Gitlab to focus on completing their Merge Train features https://gitlab.com/groups/gitlab-org/-/epics/4911… but no, that’s +2 years old epic is now pushed back again because they want to try to build some green field projects.
Meanwhile, Github has been consistently delivering features for the last few years and did not get distracted by “Kubernetes Firewall” or “Serverless”. They win.
But can it rebase? They didn’t mention that.
We use Mergify as a bot to babysit the GitHub merge train at my job. It can rebase, and we have set it to always rebase before merge, but it can’t autosquash your fixups yet, so that’s still manual labor. It also sort of supports dependent PRs, but GitHub being GitHub, it doesn’t quite work.
The world is stubbornly not perfect yet. Except, I’ve used Gerrit, which was very different and very right if you like the rebase workflow. You don’t need fixup commits, because you can just force push and it shows what you actually did different each time, or if it was a trivial rebase.
Is this what the
borsbot calls rollup?Not, it’s bors without rollup. It goes PR by PR.
Yay! This has been one of my most wished-for features for GitHub for years. Hopefully next they’ll get to tracking comments across updates to PRs, allow stackable PRs, and support *BSD in Actions, and then I will have nothing left to complain about.
While it’s not an official GitHub feature, you can use https://github.com/vmactions to run BSDs and Solaris on GitHub Actions (using VirtualBox on macOS).
I might try it again soon. I’ve move recently been trying this one. With a third-party reimplementation of the actions runner, I’ve managed to self-host some FreeBSD VMs as action runners, but I’d love to see this become officially supported, especially with GitHub-hosted runners.
That one is even more interesting to me because of the multi-arch support. Thanks!
I ended up switching back to vmactions. The xhyve implementation is somewhat flaky and we had jobs just wait for timeout before exiting, even though the tests pass fine in VirtualBox.
Well, I sure hope they have ironed out more of the bugs than I have seen. My last organization used this in the private beta and it was … well, fickle. Of course, it’s been a whole month since I have used it last, so it very well could have changed.
At one point, we got a refund of 2/3 of our minutes because of all of the duplicated CI runs. We also saw that when the head of the queue merged and changed the
mainSHA, it would then stop all subsequent jobs and restart them with the new SHA (even though the whole point of the queue is that it should already be applied :shrug:). Early on we had to actually force-stop all non-head-of-the-queue jobs because we would both run out of parallelization and the jobs would restart anyways. We would constantly see the queue get “stuck” and have to stop all of the jobs and then requeue (AKA hit the green merge button in the PR) all of the branches. It was nearly a full-time job babysitting the MQ.In theory, though, this is a fantastic way to not force everyone into “Branch must be up to date with
mainbefore merge” but still get all of the benefits.This sounds like a lot of issues. Did you try other solutions on the market yet?
I can vouch for https://github.com/bors-ng/bors-ng
Have been using it for variety of OSS projects, large and small, for years, it mostly just works.
This is how GitHub has deployed itself for years, using a bunch of internal tooling. Nice to see they’ve finally built it in and made it available to others.
Sad to see this only available for enterprise orgs. While a lot of non enterprise orgs probably don’t need something like this, it’s still useful at smaller scales but not a whole $17/user/month more useful.