The freestyle build job is the most flexible and configurable option, and can be used for any type of project. It is relatively straightforward to set up, and many of the options we configure here also appear in other build jobs.
The first section you see when you create a new freestyle job contains general information about the project, such as a unique name and description, and other information about how and where the build job should be executed (see Figure 5-2).
Figure 5-2. Creating a new build job
The project name can be anything you like, but it is worth noting that it will be used for the project directory and the build job URL, so I generally avoid names with spaces. The project description will go on the project home page—use this to provide an overview of the build job’s goals and context. HTML tags will work fine in this field.
The other options are more technical, and we will be looking at some of them in detail later on in the book.
One important aspect that you should think about upfront is how you want to handle build history. Build jobs can consume a lot of disk space, especially if you store the build artifacts (the binary files, such as JARs, WARs, TARs, etc., generated by your build job). Even without artifacts, keeping a record of every build job consumes additional disk space and memory, which may or may not be justified, ...