<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>

CC BY-SA 3.0
2017-06-16T10:46:31.530Z
Thanks for the tip on Zuul... Is it solvable on something like GitLab, Gerrit, or Stash/Crucible ? (Added to the original question)
Yeraze
CC BY-SA 3.0
2017-06-16T18:24:59.093Z
@Yeraze answered that too.
chupasaurus
CC BY-SA 3.0
2017-06-16T08:06:09.237Z
2017-06-16T18:24:15.903Z
2017-06-16T18:24:15.903Z
chupasaurus
<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>

CC BY-SA 3.0
2017-06-16T23:19:42.767Z
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).
Dan Cornilescu
CC BY-SA 4.0
2019-08-06T17:26:42.767Z
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.
casey vega
<jenkins><gitlab><builds><bitbucket>
Jenkins Testing PR's - allowing broken builds
Yeraze
# 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.  

---

