Answers: <p>Running CI pipelines in branches is a foundational practice in continuous integration -- Check whether the application can build at every change.</p>
  <p>By running a pipeline when a Merge Request is opened, you are preparing for the actual merge event, which is precisely what you aim to achieve by opening the Merge Request in the first place. Correct me if I'm wrong, but your question is related to the merge commit not the merge request, right?</p>
  <p>What you are asking however seems to be why that same change, once merged, needs to run again through the same pipeline. The answer lies in whether the branch pipeline and the mainline pipeline are identical. If the exact same tests and tasks are run in the branch pipeline as in the mainline pipeline once merged, I can understand your perplexity.</p>
  <p>However, there are very often extra or different stages which get run in a mainline pipeline. For example, a branch pipeline might perform continuous delivery to a testing or staging environment, while the mainline pipeline might deploy to the production environment.</p>
  <p>Different secrets may be consumed, changes in the production environment state may have occured, or simply a release may need to be cut and delivered to the artifactory, <em>etc</em>, <em>etc</em>. Delivering and testing changes is very different to actually deploying them into a user-facing environment.</p>
  <p>If it seems like a trivial duplication of work, this may be a signal that the pipelines need to be re-looked at and refined. At the very least, you can agree that every change to the mainline branch should be tested, therefore every commit should be tested, therefore also merge commits should be tested.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-05-04T11:38:22.543Z
Answers: _Correct me if I'm wrong, but your question is related to the merge commit not the merge request, right?_
  In our case, pipeline in some branch is triggered when I push new code to this branch. It's  obvious behavior. After I want to merge this branch into master I create new MR and pipeline starts again. Same pipeline which was triggered before, if I'm not mistaken. 
  Is it correctly or new merged code will be used in this case? I was talking about situation before I hadn't yet pressed the Merge button.  New merged code will be used in case after I press Merge, obviously.
Answers: VladF
Answers: CC BY-SA 4.0
Answers: 2023-05-04T11:39:58.950Z
Answers: Hope you undestand me clearly :-) When I do MR, two pipeplines start: one before I press Merge and other after I press merge. My question related to the first.  Obviously, the second pipeline use new merged code and it's strongly usefull and needed.
Answers: VladF
Answers: CC BY-SA 4.0
Answers: 2023-05-04T14:59:17.053Z
Answers: I think this may be due to the way you're merging - using a rebase with merge commit, for example? This will result in two commits to the branch, hence two triggers. Perhaps you should  modify the job triggers?
Answers: Bruce Becker
Answers: CC BY-SA 4.0
Answers: 2023-05-04T10:20:28.980Z
Answers: 2023-05-04T10:20:28.980Z
Answers: Bruce Becker
Body: <p>Can you explain what the point of starting pipeline for source branch again when I do MR in default branch? I mean, when I did git push before in my feature branch which I want to merge with master, pipeline was successful in that case. Why should we start it again in MR? Is it correctly if I configure except MR for stages in pipeline?
  <a href="https://i.sstatic.net/UiZvr.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/UiZvr.png" alt="enter image description here" /></a></p>
  
Tags: <gitlab><cicd>
Title: What is the point of starting pipeline when MR creating?
UserDisplayName: VladF
ThreadText: # What is the point of starting pipeline when MR creating?
  
  (Asked by: username_0 on 2023-05-04)
  
  Can you explain what the point of starting pipeline for source branch again when I do MR in default branch? I mean, when I did git push before in my feature branch which I want to merge with master, pipeline was successful in that case. Why should we start it again in MR? Is it correctly if I configure except MR for stages in pipeline?
  [![enter image description here](https://i.sstatic.net/UiZvr.png)](https://i.sstatic.net/UiZvr.png)
  
  **Tags:** gitlab, cicd
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-05-04. Score: 0 | Accepted answer
  
  Running CI pipelines in branches is a foundational practice in continuous integration -- Check whether the application can build at every change.
  
  By running a pipeline when a Merge Request is opened, you are preparing for the actual merge event, which is precisely what you aim to achieve by opening the Merge Request in the first place. Correct me if I'm wrong, but your question is related to the merge commit not the merge request, right?
  
  What you are asking however seems to be why that same change, once merged, needs to run again through the same pipeline. The answer lies in whether the branch pipeline and the mainline pipeline are identical. If the exact same tests and tasks are run in the branch pipeline as in the mainline pipeline once merged, I can understand your perplexity.
  
  However, there are very often extra or different stages which get run in a mainline pipeline. For example, a branch pipeline might perform continuous delivery to a testing or staging environment, while the mainline pipeline might deploy to the production environment.
  
  Different secrets may be consumed, changes in the production environment state may have occured, or simply a release may need to be cut and delivered to the artifactory, *etc*, *etc*. Delivering and testing changes is very different to actually deploying them into a user-facing environment.
  
  If it seems like a trivial duplication of work, this may be a signal that the pipelines need to be re-looked at and refined. At the very least, you can agree that every change to the mainline branch should be tested, therefore every commit should be tested, therefore also merge commits should be tested.
  
  > **Comments:**
  > **username_0**: _Correct me if I'm wrong, but your question is related to the merge commit not the merge request, right?_ In our case, pipeline in some branch is triggered when I push new code to this branch. It's  obvious behavior. After I want to merge this branch into master I create new MR and pipeline starts again. Same pipeline which was triggered before, if I'm not mistaken.  Is it correctly or new merged code will be used in this case? I was talking about situation before I hadn't yet pressed the Merge button.  New merged code will be used in case after I press Merge, obviously.  
  > **username_0**: Hope you undestand me clearly :-) When I do MR, two pipeplines start: one before I press Merge and other after I press merge. My question related to the first.  Obviously, the second pipeline use new merged code and it's strongly usefull and needed.  
  > **username_1**: I think this may be due to the way you're merging - using a rebase with merge commit, for example? This will result in two commits to the branch, hence two triggers. Perhaps you should  modify the job triggers?  
  
  ---
  
  