2 ms·

or you give your CI the ability to read transaction markers in your git repo. e.g. add a tag that says "must have [repo] at [sha]+". dependency management bas

by Groxx 9y ago

or you give your CI the ability to read transaction markers in your git repo. e.g. add a tag that says "must have [repo] at [sha]+". dependency management basically. you can even do this after the commits are created, so you can allow cycles and not just diamonds. but yes, cross-project commits are dramatically easier in a monorepo, I entirely agree with that - they essentially come "for free".

joshuamorton 9y ago
Didn't you just reinvent versioning and frozen dependencies? What you described is not always building at latest, it's building at latest except when there are issues at which point you don't build at latest and instead build at a known good version. Consequences of this are, for example, that you cannot run all affected tests at every commit.
- 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

Didn't you just reinvent versioning and frozen dependencies? What you described is not always building at latest, it's building at latest except when there are issues at which point you don't build at latest and instead build at a known good version. Consequences of this are, for example, that you cannot run all affected tests at every commit.

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.