Skip to main content
Jump to: navigation, search

Papyrus/Papyrus Developer Guide/How to use the Hipp and its functionalities

This page is about the basic know-how and tips about the Papyrus Hipp, which can be found here. This page is not intended to be exhaustive and curious readers might want to take a look at the official Hudson page. Be mindful that most of the described actions are only accessible to committers, administrators or persons given special rights on jobs, as most contributors won't be able to see the items described further down.


The front page will list all the jobs that are present on the Hudson page and are available to the user under the All view. Those same jobs are listed under their respective Views in order to separate them more efficiently and improve the overall vision.

Their disk consumption, for both build artifacts, logs and workspaces can be viewed here. Be mindful that those numbers do not increase to unreasonable sizes so as to not cannibalize the community's server resources for nothing.

The actions available to committers


Those actions enable the user to create jobs and views as well as configure them to meet their needs.

What is a View

Hudson main pages can have a long list of configured jobs and therefore make it difficult for users and administrators to gather the information they need at a glance and find the job they are interested in. Hudson supports the addition of user specific views to the main page to filter out unnecessary jobs.

front page

For example, from all those jobs, the Neon view can be created by selecting the relevant jobs from this pool.

front page

resulting in the following view:

front page

In this view you can see all the selected jobs as well as additional information such as the last successful build [1], the last failed build [2], the time taken by the last build (successful or not) [3] as well as its resulting console output [4]. Committers can also run new builds by clicking on the trigger button [5].

Creating a job

To create your own job, click on the Create new task and give it a name [1]. This name should limit itself to the component's name. Afterwards you can either choose to create it from scratch or clone an existing job that could be adapted to your needs [2].

front page

Job interface

The job will then have a user interface displaying various possibilities, provided the user has the rights to do so:

job interface

  1. Edit the job's name: a simple string that should respect the following rules, [Name of the component]-[title/purpose of the job].
  2. Edit the job's description: there too a simple string description which you can spice with html to format its description and insert, for example, links to other pages.
  3. Edit the job further: see the configuration example page.
  4. Trigger a new build: just launch a new build with the provided arguments.
  5. The log of previously built instances: where you can see the active and past builds as well as their console outputs going back to the time-frame provided during the job configuration (see point 3).
  6. Browse the workspace created and used by the job.
  7. Browse the build resulting artifacts: those can be created by feeding the location of the p2 target repository to the job during the archiving of artifacts.
  8. Browse the last changes in the git repository and their related commits: these will represent all the commits done and merged on the branch corresponding to the job during a the period of time corresponding to the kept builds.
  9. See the disc space taken by previous build artifacts: this should always be monitored by the person responsible for the job as it can grow to unexpected sizes if not kept in check or if the job botched a configuration.
  10. See if the build will trigger additional jobs, and which ones: will list all the jobs, and their job numbers, triggered by it.
  11. See which builds were selected to be kept forever (or at least until someone doesn't need them anymore): The user has the possibility to keep jobs and its generated artifacts, provided they are still there when the task is performed, for any period of time he deems necessary. This can be done by navigating to the build's page, by clicking on the "keep this build forever" button on the upper right. he will then have the possibility to, and should, add a message to indicate why this has been kept. Be mindful to not keep things too long and/or for flimsy reasons.

Job Configuration

If you have to set up your own job and get into the configuration side of it, you can visit the configuration example page, mentioned in the Job Interface's third point: Edit the job further, to get examples of git and gerrit jobs.

Back to the top