4 ms·

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

tokenizerrr 11y ago
A CI test result is tied to a particular commit hash. If you change this commit hash the CI test result will no longer be tied to that one commit.
plorkyeran 11y ago
The results from previous CI runs are no longer connected to the rebased commits, and most people don't have CI set up to retest each commit individually after a rebase. I've never found this to be an actual problem in practice.
tehbeard 11y ago
Since a rebase changes the commit sha, I assume that's used as a reference for which version of the code the CI test was run against. That said, shouldn't CI be triggered after the rebase anyway to confirm all still works?
- solutionyogi 11y ago
  I see. But as you noted, one must do CI tests again after a rebase.
  - sytse 11y ago
    Indeed you need to do them again. But you also have to rerun them after a merge anyway. The problem is that you can no longer see which commits that you merged where green before the merge. For example is very useful if the merge itself breaks the tests (uncommon but it can happen).
    - Mithaldu 11y ago
      Edit: There's a well-written solution for that here: https://news.ycombinator.com/item?id=9745367 https://news.ycombinator.com/item?id=9745367
      - sytse 11y ago
        Parent was deleted.
        Mithaldu 11y ago
        Ugh dammit. Short version: Instead of taking the branch <feature> and rebasing it, make a branch called <feature>.1 on top of <feature>, then rebase that, leaving <feature> in place. That way all your references remain intact and you can compare CI results. Increment the number as needed.
        sytse 11y ago
        It solves the issue of the CI references. But it also seems a bit clumsy to me.
        Mithaldu 11y ago
        It's all trade-offs. The trade-off being that you maintain history by having copies of a branch around, while the dude trying to fix a bug doesn't have to break out the vodka bottle upon arriving back home. :)

A CI test result is tied to a particular commit hash. If you change this commit hash the CI test result will no longer be tied to that one commit.

plorkyeran 11y ago

The results from previous CI runs are no longer connected to the rebased commits, and most people don't have CI set up to retest each commit individually after a rebase. I've never found this to be an actual problem in practice.

tehbeard 11y ago

Since a rebase changes the commit sha, I assume that's used as a reference for which version of the code the CI test was run against. That said, shouldn't CI be triggered after the rebase anyway to confirm all still works?

solutionyogi 11y ago
I see. But as you noted, one must do CI tests again after a rebase.
- sytse 11y ago
  Indeed you need to do them again. But you also have to rerun them after a merge anyway. The problem is that you can no longer see which commits that you merged where green before the merge. For example is very useful if the merge itself breaks the tests (uncommon but it can happen).
  - Mithaldu 11y ago
    Edit: There's a well-written solution for that here: https://news.ycombinator.com/item?id=9745367 https://news.ycombinator.com/item?id=9745367
    - sytse 11y ago
      Parent was deleted.
      - Mithaldu 11y ago
        Ugh dammit. Short version: Instead of taking the branch <feature> and rebasing it, make a branch called <feature>.1 on top of <feature>, then rebase that, leaving <feature> in place. That way all your references remain intact and you can compare CI results. Increment the number as needed.
        sytse 11y ago
        It solves the issue of the CI references. But it also seems a bit clumsy to me.
        Mithaldu 11y ago
        It's all trade-offs. The trade-off being that you maintain history by having copies of a branch around, while the dude trying to fix a bug doesn't have to break out the vodka bottle upon arriving back home. :)