Answers: <p>On GitHub - you can't. Basically, their PRs are temporary branches, and there's no check if base commit is HEAD of branch to merge in.
  This problem is solved with gating systems like <a href="https://docs.openstack.org/infra/zuul/index.html" rel="nofollow noreferrer">Zuul</a>, which puts all PRs into queue to run tests.</p>
  
  <p>You are talking about systems for managing and storing code, while the issue is in CI scope (i.e. <a href="https://about.gitlab.com/2014/09/29/gitlab-flow/" rel="nofollow noreferrer">Gitlab flow</a> has this issue described in "Testing before merging" paragraph), Zuul is made exactly to fix this problem, because the amount of merges to OpenStack codebase per day is large (year ago they had 6 zuul instances to run tests for merges).</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-16T10:46:31.530Z
Answers: Thanks for the tip on Zuul... Is it solvable on something like GitLab, Gerrit, or Stash/Crucible ? (Added to the original question)
Answers: Yeraze
Answers: CC BY-SA 3.0
Answers: 2017-06-16T18:24:59.093Z
Answers: @Yeraze answered that too.
Answers: chupasaurus
Answers: CC BY-SA 3.0
Answers: 2017-06-16T08:06:09.237Z
Answers: 2017-06-16T18:24:15.903Z
Answers: 2017-06-16T18:24:15.903Z
Answers: chupasaurus
Body: <p>I have a very large codebase that currently takes ~30 minutes to build via Jenkins.  It's connected to our Source control/review system (Let's just say GitHub for now) so that every PR automatically gets tested and must build before we allow it to be merged.</p>
  
  <p>We're seeing a behavior where 2 PR's (We'll call them PR#a and PR#b) can exist and each one is tested successfully (code builds, unit tests run, etc).  However, they're each tested against the tip of develop.  That means once PR#a is merged, PR#b shows that's been tested and valid.. However merging it exposes an API break merged as part of PR#b, and now the build is broken pending a fix.</p>
  
  <p>What's the typical way to prevent this? If not in GitHub, what about other systems? (GitLab, Gerrit, or Stash/Crucible ?)</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-06-16T23:19:42.767Z
Comments: FWIW, this is the 1st in my list of [pre-commit verification myths](https://www.apartsw.com/insights/2016/11/16/pre_commit_verification_myths.html).
Comments: Dan Cornilescu
Comments: CC BY-SA 4.0
Comments: 2019-08-06T17:26:42.767Z
Comments: How often do you re-index? Setting this time to a lower value (e.g. 5 minutes) will cause Jenkins to rescan the master branch, pick up changes, and rebuild the PR.
Comments: casey vega
Tags: <jenkins><gitlab><builds><bitbucket>
Title: Jenkins Testing PR's - allowing broken builds
UserDisplayName: Yeraze
ThreadText: # Jenkins Testing PR's - allowing broken builds
  
  (Asked by: username_0 on 2017-06-16)
  
  I have a very large codebase that currently takes ~30 minutes to build via Jenkins. It's connected to our Source control/review system (Let's just say GitHub for now) so that every PR automatically gets tested and must build before we allow it to be merged.
  
  We're seeing a behavior where 2 PR's (We'll call them PR#a and PR#b) can exist and each one is tested successfully (code builds, unit tests run, etc). However, they're each tested against the tip of develop. That means once PR#a is merged, PR#b shows that's been tested and valid.. However merging it exposes an API break merged as part of PR#b, and now the build is broken pending a fix.
  
  What's the typical way to prevent this? If not in GitHub, what about other systems? (GitLab, Gerrit, or Stash/Crucible ?)
  
  **Tags:** jenkins, gitlab, builds, bitbucket
  
  > **Comments:**
  > **username_1**: FWIW, this is the 1st in my list of [pre-commit verification myths](https://www.apartsw.com/insights/2016/11/16/pre_commit_verification_myths.html).  
  > **username_2**: How often do you re-index? Setting this time to a lower value (e.g. 5 minutes) will cause Jenkins to rescan the master branch, pick up changes, and rebuild the PR.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2017-06-16. Score: 2 | Accepted answer
  
  On GitHub - you can't. Basically, their PRs are temporary branches, and there's no check if base commit is HEAD of branch to merge in.
  This problem is solved with gating systems like [Zuul](https://docs.openstack.org/infra/zuul/index.html), which puts all PRs into queue to run tests.
  
  You are talking about systems for managing and storing code, while the issue is in CI scope (i.e. [Gitlab flow](https://about.gitlab.com/2014/09/29/gitlab-flow/) has this issue described in "Testing before merging" paragraph), Zuul is made exactly to fix this problem, because the amount of merges to OpenStack codebase per day is large (year ago they had 6 zuul instances to run tests for merges).
  
  > **Comments:**
  > **username_0**: Thanks for the tip on Zuul... Is it solvable on something like GitLab, Gerrit, or Stash/Crucible ? (Added to the original question)  
  > **username_3**: @username_0 answered that too.  
  
  ---
  
  