Overview

You will interact with jenkins whenever you submit a merge proposal. Jenkins will insure your proposal builds properly and merges cleanly with trunk. In addition, it will run the any unit tests. The result of these actions will be left as a comment on your merge proposal saying if your code passed or failed these actions. A failure occurs whenever a proposal doesn't build, or merge cleanly. It will also fail if the test runs on the phone fail.

Here's an example of what you will see on your merge proposal.

Troubleshooting

Something broken? Nothing happening? Follow these steps to troubleshoot.

1. Check on the status of the build slaves and master. If anything shows as disconnected, file an RT to webops to fix. If only the krillin is showing as disconnected, you may alternatively ask plars to reconnect it.

2. Check the build queue. If it's backed up, give it time to resolve itself. If a job has been running for a LONG time, cancel the job to get the queue moving again. Do this by pressing the red 'X' next to the running job. To fix this, click those red X's! Don't worry, the jobs will re-generate automatically without issue.
   

3. The phone testing device seems broken! Run the following job to recover and reflash the device to a stable build.

4. If the tests are failing, or something is happening with the phone device and you still need to land your code, simply top-approve and jenkins will merge anyway.

If all else fails, or you just don't know what to do, file an RT.

Running jobs

'NOTE: In order for you to request new builds, you will need to login and be a member of the core-apps development teams.'

While jenkins will automagically run on any new merge proposals, should you wish to run something manually, you can do so.

Re-reruning a build

If you simply want to re-run a build, click the link on the jenkins comment to rebuild. You can also browse jobs, and select re-run on any job to re-run it.

Running autopilot tests on a branch

You can build and run any branch you wish using the release-build-test job. It will first build the app, then quick off a run of run-ap-tests-release which will contain the testrun output.

Run a build against a branch

You may run a job at any time for a branch; even without a merge proposal. To do so, find the corresponding *-ci job and start a new build. Select the Build with parameters link, NOT the configure link. Here's an example of building the weather app. Note, just leave the merge proposal field blank.

Run a build against a merge proposal

You can also build for a merge proposal; anyone you wish. Fill out the build parameters as above, but also include the link to the MP. Jenkins will run as usual.

Releasing to the store

This is done in coordination with popey, who will prepare a full test run using the release- jobs and coordinate manual testing with QA.

Viewing Results

Viewing Artifacts

Jenkins will leave a comment in merge proposals with a link to the jobs that ran your code. Clicking the link will take you to a page where you can view the artifacts from a build, including the click package and logs.

Using trv

You can use the trv tool to view the subunit files that are the outcome of a testrun. This will nicely display the test log and a screenshot of your application at the point of failure. Check out this video for more on how to use the app. You'll want to download the autopilot.subunit files to open with this.

Jobs

Jenkins has an assortment of jobs that help perform the tasks of merging and testing your proposal.

Where's the code?

All the scripts to test and run the code can be found under lp:~ubuntu-core-apps-jenkins/jenkins/scripts.

Job Naming

• jobs specific to an app start with the app name. e.g. weather-app-trigger-ci, weather-app-ci, weather-app-autolanding

• trigger jobs all end with trigger-ci

• build jobs all end with -ci

• Running AP tests on the phone is run-ap-tests-*

• Release jobs for preparing a click for release are under the release tab, and start with release-

• generic-update-mp, generic-land-mp deal with commenting on merge proposals

Workflow

An unapproved merge proposal

First, a trigger job that is watching the project for new merges is triggered. From there 3 more jobs are run. The first builds the click, the second runs the tests, and the lastly the final job comments on the results are run.

Process

The overall flow then looks like this

*app-trigger-ci->*app-ci->generic-update-mp

Here's a full example:

filemanager-app-trigger-ci->filemanager-app-ci->generic-update-mp
^ watches for new MP        ^ builds the click  ^ comments on MP

A top approved merge proposal

The process is much the same. The primary job however is *-autolanding, instead of *-ci. For example, to land a filemanager change, the following jobs are called:

filemanager-app-trigger-ci->filemanager-app-autolanding->generic-land-mp
^ watches for new MP        ^ builds the click           ^ merges to trunk,comments on MP

Other jobs

There are some other jobs that help keep things running. They can be found under Maintenance Jobs. These do things like maintain the chroots (updating / upgrading them on a regular basis) and the phone device (re-flashing it once a week, currently on Sunday).

Chart

This flowchart shows the workflow for submitting and releasing the core apps.