3 ms·

So they reinvented OpenStack's Zuul? I've always thought if you're pushing changes at the sort of velocity that requires it, you're doing something wrong, anyw

by inigyou 3mo ago

So they reinvented OpenStack's Zuul? I've always thought if you're pushing changes at the sort of velocity that requires it, you're doing something wrong, anyway.

conradludgate 3mo ago
In my experience, it's a monorepo problem. We have a monorepo at work and the CI only runs a minority of tests prior to merging, and then reverts bad commits later. It can take a few hours until every test has run including your commit. I don't know enough about the setup to know how it decides to run what tests though
- inigyou 3mo ago
  Yeah that's true. It becomes O(N^2) with one factor of N being the number of commits to the repo, and another factor being the amount of CI stuff you do every time the repo changes.
  - AlotOfReading 3mo ago
    You can do better than O(N^2) if your changes are monotonic /independent (or you're able to cache for basically the same reason). This usually requires either luck, a huge amount of programmer discipline, or very different programming languages than we're used to like unison.
- orf 3mo ago
  How does it handle conflicts during reverting? If another merge depends on a change, and that change causes a failing/broken test, does it revert both?
- fweimer 3mo ago
  It's not really about a monorepo, but how many changes you can have in flight in parallel. Desirability of merge-and-rebase-and-check depends on more factors: the rate of change, the number of developers, the time the pre-merge checks take and the reliability of those checks, and how often pre-merge checks fail (legitimately or otherwise). How conflict-prone queue changes are matters, too. I would like to have something like this for one of the repositories I work on, which is pretty far away from being a monorepo (it's mainly producing two tightly interlinked binary objects). Fortunately, I believe Gitlab offers something like it, at least as a preview feature (under the namemerge-and-rebase or something like that).

by inigyou 3mo ago

So they reinvented OpenStack's Zuul? I've always thought if you're pushing changes at the sort of velocity that requires it, you're doing something wrong, anyway.

conradludgate 3mo ago

In my experience, it's a monorepo problem. We have a monorepo at work and the CI only runs a minority of tests prior to merging, and then reverts bad commits later. It can take a few hours until every test has run including your commit. I don't know enough about the setup to know how it decides to run what tests though

inigyou 3mo ago
Yeah that's true. It becomes O(N^2) with one factor of N being the number of commits to the repo, and another factor being the amount of CI stuff you do every time the repo changes.
- AlotOfReading 3mo ago
  You can do better than O(N^2) if your changes are monotonic /independent (or you're able to cache for basically the same reason). This usually requires either luck, a huge amount of programmer discipline, or very different programming languages than we're used to like unison.
orf 3mo ago
How does it handle conflicts during reverting? If another merge depends on a change, and that change causes a failing/broken test, does it revert both?
fweimer 3mo ago
It's not really about a monorepo, but how many changes you can have in flight in parallel. Desirability of merge-and-rebase-and-check depends on more factors: the rate of change, the number of developers, the time the pre-merge checks take and the reliability of those checks, and how often pre-merge checks fail (legitimately or otherwise). How conflict-prone queue changes are matters, too. I would like to have something like this for one of the repositories I work on, which is pretty far away from being a monorepo (it's mainly producing two tightly interlinked binary objects). Fortunately, I believe Gitlab offers something like it, at least as a preview feature (under the namemerge-and-rebase or something like that).