Pre merge builds of GitHub pull requests

When a pull request gets created or updated a build will be triggered on our Jenkins CI server. The build results will be visible on the public Jenkins; the link is visible in the comment that Jenkins adds to the pull request after the build is finished. The builds can also be accessed on our internal Jenkins where they might give some more details.

Because we're building on both Windows and Linux the setup behind the scenes is slightly complicated. Unfortunately the published build results don't show all details, so it might be worth to look at the console output reachable from the linked build page.

At the time of this writing only pull requests on the BloomDesktop repo have pre-merge builds set up.

Controlling builds

A pull request created or updated by a member of the Bloom GitHub group/organisation will automatically trigger a build. For other contributors a member of the team needs to kick off a build by adding a comment to the pull request:

• "ok to test" to accept this pull request for building/testing

• "test this please" for a one time test run

• "add to whitelist" to add the author to the whitelist

If the build fails for other various reasons you can rebuild:

• "retest this please" to start a new build

If a pull request of a team member should not trigger a build, the phrase "skip ci" can be included in the pull request message.

What happens

The following illustration illustrates what happens after a pull request gets created or updated:

A new or updated pull request triggers the job GitHub-Bloom-Wrapper-debug on Jenkins which kicks off a Windows (GitHub-Bloom-Win32-PR-debug) and a Linux build (GitHub-Bloom-Linux-any-PR-debug).

After these are finished the unit tests are run by separate jobs: GitHub-Bloom-Linux-any-PR-debug-Tests and Bloom-Win32-default-debug-Tests.

Finally the wrapper job collects the output and publishes the results on our public jenkins.