Skip to content
This repository has been archived by the owner on Jan 23, 2024. It is now read-only.

Build Server

Jump to bottom
Enric Galceran edited this page Jul 28, 2015 · 24 revisions

##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 must build successfully on the build-server. (This is part of a code-review / build-test, see below).

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

To warm up, let's see how many bugs you can spot in the following example:

int main() {
  int* foo = new int[4], *bar = new int[4];
  std::thread{[&](){bar++;}}.detach();
  delete foo;
  return *foo + (*++bar) + bar[3];
}

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

####Logging in We use github as authentification backend. So after pressing the login button on any page of the build server it should take you to github for authentification. After logging in you have access to additional features including the ability to trigger builds.

####Build server gui

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 red-cross-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 or from the summary page of a build:

  • Test results: The results from gtests automatically run after the build passed.
  • Compiler Warnings: The number of compiler warnings and history thereof.
  • 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.

Creating new jobs

The best thing is to copy existing jobs.

  1. Go to the main Jenkins page http://129.132.38.183:8080/
  2. Click the button on the top right to log in.
  3. Click on "new item" from the menu on the left.
  4. Give an item name (job-name == usually the repository name)
  5. Click "Copy existing job"
  6. Enter one of the following names:
  • ethzasl_msf for a catkin or rosbuild based project
  • libnabo for a pure cmake build project or any other build-system
  1. Click ok to create the job.
  2. In the newly created project adjust the "github project" URL.
  3. Under "Source Code Management" set the URL of the repository. (e.g. SSH git link).
  4. Under "Additional Behaviours" adjust the "Local subdirectory for repo" option.
  5. Under "Build" adjust the "Execute Shell" command:
~/continuous_integration/run_build.sh 
    --dependencies="[email protected]:ethz-asl/asctec_mav_framework_devel.git" 
    --packages="msf_core msf_updates"
  • dependencies (optional) You can list a space separated lists of github repositories which your project depends on. These repositories are checkout out at the master branch and included in the build. This is required if your repository has dependencies on other projects, because otherwise the workspace will contain only your package.
  • packages (optional) You can list a space separated list of packages you want to build instead of just building all packages. This invokes rosbuild your_packages or catkin build --pkg your_packages respectively.

Administration

http://wiki.asl.ethz.ch/index.php/Server_Configuration#Build_Server

Clone this wiki locally