2 ms·

sure. I honestly don't see why that's a problem though, especially since "at every commit" can have clear markers for if it's expected to be buildable or not.

by Groxx 9y ago

sure. I honestly don't see why that's a problem though, especially since "at every commit" can have clear markers for if it's expected to be buildable or not. My point here is that you're describing a known problem with known solutions, and saying it's impossible. I'm saying it requires work, as does all this in a monorepo. edit: to be technical: yes, you're correct, it can't always build at latest at every instant. Agreed. I don't see why that's necessary though. Simplifying, sure; necessary? No.

joshuamorton 9y ago
>sure. I honestly don't see why that's a problem though, especially since "at every commit" can have clear markers for if it's expected to be buildable or not. The value from this is the ability to always know exactly which thing caused which problem. If you know things are broken now, you can bisect from the last known good state, and find the change that introduced a breakage. With multi-repo, you can't do that, since it's not always a single change that introduces a breakage, but a combination. Ensuring that everything always builds at latest allows you to do a bunch of really cool magical bisection tricks. If you don't have that, you can't bisect to find breakages or regressions, because your "bisection" is 1. now 2 dimensional instead of 1 2. may/will have many false positives That puts you in a really rough spot when there's a breakage and you don't have the institutional knowledge to know what broke it.
- Groxx 9y ago
  No, you're back to "we can't build HEAD in a multirepo", which is fixable with CI rules. If you can, you can bisect exactly the same (well, with a fairly simple addition to bisect by time. `git bisect` is pretty simple, shouldn't be hard to recreate). In any case, unless you have atomic deploys across all services, this is generally untrue. Bisecting commit history won't give you that any more in a monorepo than in a multirepo.
  - joshuamorton 9y ago
    To your first point, I'mma need you to explain how you bisect across a poset, because that's what you just claimed you could do. To your second point, nothing I've said has anything to do with deployment. We're still entirely in the realm of continuous integration.

by Groxx 9y ago

joshuamorton 9y ago

>sure. I honestly don't see why that's a problem though, especially since "at every commit" can have clear markers for if it's expected to be buildable or not. The value from this is the ability to always know exactly which thing caused which problem. If you know things are broken now, you can bisect from the last known good state, and find the change that introduced a breakage. With multi-repo, you can't do that, since it's not always a single change that introduces a breakage, but a combination. Ensuring that everything always builds at latest allows you to do a bunch of really cool magical bisection tricks. If you don't have that, you can't bisect to find breakages or regressions, because your "bisection" is 1. now 2 dimensional instead of 1 2. may/will have many false positives That puts you in a really rough spot when there's a breakage and you don't have the institutional knowledge to know what broke it.

Groxx 9y ago
No, you're back to "we can't build HEAD in a multirepo", which is fixable with CI rules. If you can, you can bisect exactly the same (well, with a fairly simple addition to bisect by time. `git bisect` is pretty simple, shouldn't be hard to recreate). In any case, unless you have atomic deploys across all services, this is generally untrue. Bisecting commit history won't give you that any more in a monorepo than in a multirepo.
- joshuamorton 9y ago
  To your first point, I'mma need you to explain how you bisect across a poset, because that's what you just claimed you could do. To your second point, nothing I've said has anything to do with deployment. We're still entirely in the realm of continuous integration.