Difference between revisions of "Papyrus/Job Configuration Example"

Revision as of 10:36, 1 March 2017

This page serves as an example of a job configuration using a simple job such as the requirement one. As a reminder: you can always | clone an existing job and tailor it to your needs if it can be adapted without much hassle.

Configure by number

The steps to be mindful of are the following:

1. If you are mindful, and you should, about the disk space your job occupies on the shared instance this is where you can manage it. Usually you should adjust the number of builds you want to keep and limit the number of build artifacts you keep. Keeping the last 2 or 3 is a good general rule. If your job is solicited frequently, such as multiple builds per day, you should instead look to keep the last X number of days. Usually keeping the same number of days as the frequency of your team meetings is a good general rule, but this should not go past the last 15 days.
2. There you can refine the authorizations given to a group of individuals or specific ones. This can be especially useful if the main contributors are not yet committers but need to be able to manage the job.
3. You should also clean your workspace before every build to get rid of unwanted remaining files or folders. As such, activating this option or running a shell script before the build (git clean -fdx that will remove files and folders from the old git configuration and preceding builds) is advised. The Clean after checkout option can also be activated to be safe as it will remove all untracked files after each checkout and prior to the build.
4. Then you will have to decide if you want to have automated builds, which you should because it makes ones life easier, and what kind of trigger should be used to launch a new one. In the example I used a reccurent trigger that launch the job every 6 hours on the 6th minute. Another way, the checkbox just after, is to set the job to check every X minutes or hours the state of the repository and launch a build if the repository has been altered. Of course, a combination of both can be done.
5. The example is done for a maven build and therefore we invoke our build strategy and the tool used to do it. The build tool will need you to give it the path to the pom to execute and the goals of the build, here clean and install, as well as any additional properties and profiles that you would like to add and trigger.
6. To build the update site you will need to archive the features contents declared in your site's category.xml and generated through the build. Hudson will then keep the specified, by the path provided, artifacts and make them available on the web interface. By filling the exclude box you can further limit the scope of the artifacts that should be published after each build.
7. The person responsible for the job should always be added in the notification box so as to get a current status on the build state should it fail.
8. Finally you have the possibility, and should use it whenever possible, to empty the workspace after each build. This is particularly useful in case of workspace degenerating in several gigabytes of files that can cannibalize the pooled disc resources on the shared instance.