Congrats - I totally see the value of this product and I like how you have taken the enterprise approach.
Asking to learn - How hard was getting SOC2 Compliance? You have an on-prem I see. Any indicative costs for that, please?
Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
51–59 of 59 posts
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#52Perfect YC business. When an engineer made a similar solution at my previous company we celebrated him for months. This seems small but you have huge potential here, good luck! :D
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#53Neat! Pretty much every large company seems to have some variation of this.
I skimmed through your documentation, but it wasn't clear if this would handle workflows like the Chromium/AOSP workflows, where you have multiple repositories that are managed together via Google's repo [0] tool to give the illusion that it is a monorepo?
Occasionally you may have changes that span repositories and either need to be merged in a specific order, or in a single shot all-or-nothing merge "batch" [1]. This dependency information would be tracked either when the changes are originally submitted together to CI or directly in the commit message.
Of course, this means that you potentially have a small window where repo syncs may pull a partial set of changes, but usually this is solved via something similar to what Chromium calls "Sync to Green" [2].
[0] https://gerrit.googlesource.com/git-repo/
[1] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/con...
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/dev...
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#54How does this compare to Bors NG? https://github.com/bors-ng/bors-ng
bors solves a similar problem, but we've found that enterprises require a lot of additional features to get their dev teams to actually use it, so we've focused on those to make this production-ready. Specifically: 1. We focus on being "no-maintenance", since our primary value prop to customers is "you won't have to spend eng resources on merge problems any more". This means: a one-click "set and forget" install, no…
We're a >200 people company that's been using bors-ng for more than 4 years now for a monorepo. It's been a joy to use Bors! I'd thought I'd just chime in a little here:
> 1. We focus on being "no-maintenance", since our primary value prop to customers is "you won't have to spend eng resources on merge problems any more". This means: a one-click "set and forget" install, no additional config files to maintain or DSL to learn, unlike bors.
Bors was a breeze to set up and has been super stable and easy to upgrade. We used their Docker container and you need a PostgreSQL database.
> 2. We have all the security and access-control features you'd want (we're Soc2 compliant, offer on-prem etc). This is important since the product interacts with our customers' source code.
For a monorepo you can get really far using Github's CODEOWNERS file and requiring an approval in bors.toml.
> 3. We offer various customizations on merge workflows to help our customers optimize the exact parameters they care about (eg: developer wait time vs CI costs vs time to identity bad PRs in a batch, optimistic merge heuristics etc)
Nice! One issue we've seen is that a large backlog of PRs that needs to be merged, combined with a failing PR, is that bifurcations can easily build up a large backlog. We've looked at various different strategies to cope with that[1].
[1] https://forum.bors.tech/t/draft-rfc-support-building-batches...
Above said, I really think the _real_ solution to handling large backlogs really lies in speeding up the CI build, not adding even more complexity to handle a backlog. This includes adding caching à-la Earthly[2] et al., but also moving away from heavy integration/system tests etc.
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#55Excited to see more stuff in this space. I've previously done some investigation into the various options [0] Questions: - Why have your own pre-conditions rather than relying on Github's built-in conditions and Status? Ideas - Autosquash fixup commits. I like to have multi-commit PRs that get merged into main. I'd like to leave my fixup commits up to make it easier for reviewers to see fixes and then have the tool d…
Wow this is amazing. May be you should add MergeQueue to your list :) - Yeh we define our own pre-conditions because some developers also use it for non-protected branches. The default picks up the Github build-in preconditions and allows you overwrite. - Can you clarify your fixup commit suggestion? So there's typically an option to squash and merge when merging the PR, but sounds like you want to maintain some of t…
> - Can you clarify your fixup commit suggestion? So there's typically an option to squash and merge when merging the PR, but sounds like you want to maintain some of those commits and squash the rest?
If you run `git commit --fixup `, git will mark the commit as a fixup for `` (via a commit message convention). Then when you run `git rebase -i --autosquash`, git will automatically move those commits to be just after what they fix and mark them as "f" (fixup) rather than "p" (pick).
When putting up PRs for review, there is a tension between making it easy for reviewers to see what has incrementally changed (depending on which PR tool you are using) and having your PR in a ready-to-land state. By having fixups resolved during the merge, you get the best of both worlds.
> Curious since you have done this much research - have you built or used any of the merge queues in your company?
At my last company, I was researching what we should replace Phab with. I was looking at a broad spectrum of features for our system, including auto-merge, merge-queues, configuration-as-code, "next step" notifications for PRs (rather than flooding all), auto-elect-from-group with load-balancing, etc. Basically, we were in a bit of an extreme for baby sitting the system and I wanted to get us to the complete opposite. Unfortunately, I left before I got to complete that work due to a unique opportunity.
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#56Really dumb question while I'm trying to decide whether to use something like git vs. CRDTs to handle version control for user changes made in an app I'm working on: why do we even use git anymore for source code version control if we want behavior like this? Nobody likes merge conflicts. We all want versioning. So long as we have versions at all why isn't the ideal interface for developing in teams something more li…
> why isn't the ideal interface for developing in teams something more like editing in Google docs
Engineering and debugging are hard enough as it is. Doing this while one or more people are changing the code in real time would be a nightmare.
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#57Nice. Good luck. I am really intrigued by the flaky test detection feature as I have worked with a team member recently to built this from scratch.
I’d love to learn more about what testing frameworks are you targeting. Or is it framework agnostic? Which would be very cool though
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#58Nice. Good luck. Really intrigued by the flaky test detection feature as worked with a team member recently to built this from scratch.
Is it framework agnostic? Which would be very cool though
Re: Launch HN: MergeQueue (YC S21) – Automate rebasing and merging for your codebase
#59This is the one true way to do things, of course ( https://graydon2.dreamwidth.org/1597.html ), but besides the "why not use bors/homu" question - what prevents GitHub or GitLab from building this in? I hope we get to a world one day where a standard feature of all pull-request-ish platforms is that merges end up on a task queue, CI runs on the merge, and the merge only happens if CI passes. It doesn't seem like a te…
That's the world I'm hoping for, as well. I'm the lead contributor to bors-ng.
Like Steve Jobs criticizing Dropbox, I think that bors is a feature, not a product. If GitHub integrated merge trains, I would probably just call it quits and put bors-ng on feature freeze, maintaining it only enough to make sure it stays working and patched for vulnerabilities while everybody migrates off of it.
There are a few reasons for this, but mostly it's because of all the unfixable bugs and limitations that are caused because bors-ng isn't a GitHub feature.
* I can't squash PRs while still having them show up as purple in the GitHub UI. GitHub just doesn't let you do that.
* The CI configuration needs to be partially duplicated between the CI system itself and bors.toml. To fix this, bors would need to implement its own GitHub Actions workflow file parser. If implementing the CODEOWNERS file is any indication, that basically means reverse-engineering GitHub's behavior, because you can bet your life their documentation won't cover every possible corner case.
* Some pull request review features need to be duplicated between GitHub itself and bors-ng, like pre-checks and CODEOWNERS, because there's no stable API to get that information.
* Bors-ng isn't allowed to modify GitHub Workflow files [1]. They just don't let GitHub Apps do that.
* Bors-ng can't always tell whether a CI error should cause the PR to be rejected, or if it's just going to be retried later [2]. To fix this, it basically need to know incident information for the CI provider, which basically means it would have to have a hotline to their ops teams, which I don't.
[1]: This is because bors-ng is an app, rather than a machine user. It would be fixable, but fixing it would make it harder to deploy.
[2]: https://twitter.com/AstraLuma/status/1300797343135137796
These are the biggest problems I have with bors-ng right now. Some of these are theoretically solveable, if you're willing to do way more work than I am, but some of them are truly impossible for anyone but GitHub to solve, and all of them are easier for GitHub to solve than they are for anyone else because they have infrastructure powers that we don't have.
It's honestly a little demoralizing.