3 ms·
Apologies for comment thread hijacking, but I have a related question I hope someone could help me understand. I have worked on many teams that did continuous
by sopooneo 5y ago
Apologies for comment thread hijacking, but I have a related question I hope someone could help me understand.
I have worked on many teams that did continuous integration, but never continuous deployment. With continuous deployment, say I branch off trunk and start to implement FeatureA. Just after that, someone else branches off trunk, implements a smaller FeatureB, and merges it back in to trunk. The next day I finish FeatureA and open a pull request back to trunk.
All unit tests pass on the code I submitted, and there are no conflicts with trunk. But still, it's not going to be a fast forward merge, so the code I submitted is different than what will be actually be deployed after FeatureA is merged to trunk. And maybe after merge, certain unit tests will fail on trunk. This same truth applies regardless if my pull request is set to squash-merge or rebase.
So my question. When do unit tests automatically get run?
1. On my feature branch after the pull request is opened?
2. On trunk after my feature branch is merged?
3. Both 1 and 2?
4. Or am I, as a submitter of code required to continually update my pull requests such that they are always going to be fast forward? That is, if I am waiting on a pull request to be merged, and someone else's PR is merged do I have to rebase my code on top of trunk every time?
|
|\
|\\
|||FeatureB
|//
|/
* Passing unit tests in FeatureB do not guarantee passing unit tests here