Build Server

##Continuous integration and the build-server Continuous integration (CI) is the practice, of building a repository several times a day, checking that there are no compilation errors and test failures. Additionally before any commit is merged to the master, it should build successfully on the build-server. (This is part of a code-review / build-test, see below).

Build tests and unit tests

We ensure the basic level of integrity by automatically building all repositories several times a day and running unit-tests. This can eliminate the following errors:

• General compilation errors caused by syntax errors, missing includes, wrong include paths.
• Missing files that are available locally but not checked into the repo.
• Hardcoded local paths for files required for build-tests.
• Depending on the unit-test coverage, this checks the correct functioning of the software.

Code review and automatic pull-request building

All code that is merged to master from a feature branch should be proposed by issuing a pull-request. The code should then be reviewed by a collaborator to catch bugs and inefficient implementations. At the time a pull-request is opened the build-server will automatically start a build. The result of this build is reported back to github where the pull-request status is updated accordingly (see below for more explanations).

###Basic usage: ####Accessing the build server The build server can be accessed from here: http://129.132.38.183:8080/

The build-server job overview looks like this:

Troubleshooting

Missing the READ permission: You need to be member of the ethzasl organization and make your membership public. If the access does not work, write a mail to [email protected]. ####Manually triggering a build

• Select a build job that you want to use from the overview page.
• Trigger a job by clicking "Build with Parameters"

• Specifying a branch or the SHA of a particular commit.
• Click build to start the build.

Automatically triggered builds for pull-requests

• When you send a pull-request (Code-review-process) to a repository which is integrated to the build-server, a build will be automatically triggered.
• Whenever you push a new commit to a branch where there is a pull-request opened already, this new commit will be automatically build.
• To manually rebuild the last commit of a pull-request, add the following comment to the pull-request: Jenkins test this please using the commenting function at the pull-request page.

The status of a build is marked in two ways:

• Next to each commit a check-mark or cross signals if a build was successful. Clicking on the icon takes you to the build-status page on the build server.
• The merge button at the end of the pull-request is yellow if the build failed or is pending. The button turns green if the build is successful.

Never merge a branch that does not build on the build-server.

Debugging failed builds

Access the failed build by clicking the icon next to a commit in a pull-request.

• Click on Console-Output to access the output of the compiler. (You might need to click on "full-log" at the top to see the full output).
• You can use the "Parsed Console Output" menu item from the menu on the left to access filtered output with just errors and warnings.

Analyzing the build results

You can access particular builds for a project:

• by going to the build-server, project page, then picking a build-number from the list on the left.
• by clicking the icon next to a commit in a pull-request.

You can now see a couple of additional tools, by selecting their summary pages from the menu on the left:

• Test results: The results from gtests automatically run after the build passed.
• Open Tasks: The code-base is automatically crawled for comments including TODO or FIXME and these are then summarized.
• Cpp-check: A static analysis is run on the code to identify common problems. E.g. null-ptr dereferencing, undefined value usage etc.