3 ms·
Cool. Now let me do it across multiple repos. I often end up with 10 or 20 PRs across a half dozen repos that need to be merged in specific order.
by inetknght 6mo ago
Cool. Now let me do it across multiple repos. I often end up with 10 or 20 PRs across a half dozen repos that need to be merged in specific order.
- throwaway9980 6mo agoWho hurt you?
- dpcx 6mo agoTheir manager who suggested that everything be a microservice, but everything depends on each other.
- deleted 6mo ago[deleted]
- simplyluke 6mo agoMicroservices, by the sound of the original comment
- Arbortheus 6mo agoMicroservices without a monorepo is hell
- Yokohiii 6mo agoThey've opted for critical damage.
- whalesalad 6mo agoFor sure. If you are in a monorepo this solution works but if you have distinct microservice repositories it would help to coordinate pr #827 on repo-A and pr #1092 on repo-B are related and need to ship in a certain order.
- ZeWaka 6mo agoExact problem we've run into at work. We've ended up having to write external merge coordination in order to not break our dev deployments.
- ameliaquining 6mo agoHow would that work? Commits in different repos aren't ordered relative to one another. I suppose you could have a "don't let me merge this PR until after this other PR is merged" feature, but you could do that with a GitHub Action; it doesn't really need dedicated backend or UI support.
- inetknght 6mo ago> How would that work? In practical terms: I manually write a list of PRs, and maintain that list in the description of each of the PRs. Massive duplication. But it clearly shows the merge train.