Question: You list Uber (my employer) as a user in your homepage, but searching internally, the only search result for mergify is a mergify.yml in some random debian module for lua, so it doesn't seem like we actually use it for anything (and we built an in-house solution for the repos w/ serious commit traffic). I'm curious how you determine who your corporate users are?
Comment: we ended up building a merge queue in house because frankly build/test pipelines can look very different,(e.g. at one point we had jenkins pipelines and buildkite pipelines, some using bazel, some not, talking to phabricator instead of github, etc). At the end of day plugging in a merge queue technology requires a bunch of work integrating with a myriad of things anyways. Since the engineering effort is relatively high regardless, doing it in house lets us experiment with more aggressive optimization heuristics than just waiting on a 3rd party.
We know Uber has some great internal tooling (there's even a paper published on their merge queue: https://eng.uber.com/research/keeping-master-green-at-scale/). We had various Uber engineers using Mergify on open source repositories those last years. I didn't check recently if that was still the case, I'll make sure our lis is not too much outdated.
I definitely agree with your view on how pipelines can be different. I think none of our customers has something that is exactly the same. However, many of them don't have the workforce to build in house or even to optimize as far as you would do in a (very) large company.
lhorie|3 years ago
Question: You list Uber (my employer) as a user in your homepage, but searching internally, the only search result for mergify is a mergify.yml in some random debian module for lua, so it doesn't seem like we actually use it for anything (and we built an in-house solution for the repos w/ serious commit traffic). I'm curious how you determine who your corporate users are?
Comment: we ended up building a merge queue in house because frankly build/test pipelines can look very different,(e.g. at one point we had jenkins pipelines and buildkite pipelines, some using bazel, some not, talking to phabricator instead of github, etc). At the end of day plugging in a merge queue technology requires a bunch of work integrating with a myriad of things anyways. Since the engineering effort is relatively high regardless, doing it in house lets us experiment with more aggressive optimization heuristics than just waiting on a 3rd party.
jd__|3 years ago
I definitely agree with your view on how pipelines can be different. I think none of our customers has something that is exactly the same. However, many of them don't have the workforce to build in house or even to optimize as far as you would do in a (very) large company.