2 ms·

Correct, the pipeline is automatically restart, but it takes a good 5 minutes to run to completion in which time another developer might sneak in a merge and th

• cryptonector 8y ago
  Merge or rebase is orthogonal to CI/CD.
  • umvi 8y ago
    Our policy is that code can't merge until CI passes. If you rebase, you have to restart CI. If another developer merges, you have to rebase. As a result I sometimes get stuck in a cycle where I'm not fast enough on the trigger and it's difficult to get my code merged because while I am waiting for CI to pass, someone else merges and I get to rebase and start CI over.
    • chrisseaton 8y ago
      Right, but how's that different between a rebase and a merge commit? In both cases, new commits appear and you need to re-run to get your commit (merge or rebased) in on top of them.
    • cryptonector 8y ago
      When you merge you still need to restart the CI. You're taking a shortcut if you have a head that passed CI, do a merge w/ no conflicts and push without redoing the CI. EDIT: And you can totally take that same shortcut with rebase. Yes, with rebase you've lost the metadata about the previous head, but you can actually keep it by including a merge commit whose only purpose is to record the previous head of your branch (you can strip these out at push time, or keep them if you like, but they will essentially be useless -- at Sun we called merge commits "turds"). Merge-vs-rebase is totally orthogonal to CI/CD, but if you find that "merging means not restarting the CI" then you've already got a bias in favor of merging in your policies and tooling, and that's why you have that perception. I would challenge you to understand how your CI/CD is forcing a merge workflow rather than merely accepting it unquestioningly.