Freestyle jobs

Freestyle job configuration is split across a number of sections, each of which is detailed below. Most individual options also have their own help information available.

General options

There are a number of basic options which you may want to consider when configuring a freestyle job.

Top level options
Top-level options on the configuration page


The description can be used to store extra information about the build. This can be particularly useful if the job has multiple administrators.

Parameterised builds

By selecting This project is parameterised you can add a wide range of parameters to the build job. For example a string parameter could be used to provide a version number for a build script, or a boolean parameter could specify whether to upload the build output. These parameters are then specified at build time through the web interface.

Concurrent builds

In its default state Anvil will not run concurrent builds of a particular freestyle job - this is the opposite to pipeline jobs. Choosing Execute concurrent builds if necessary will allow this to occur. This is recommended for the majority of jobs.

Advanced Options

Very few of the advanced options are generally useful, however you may want to set the Display Name.

Advanced options
Advanced options on the configuration page

Display name

The display name is shown in the web interface in preference to the item name set during the creation of a job. You may want to set this if your item name is not descriptive.

Source Code Management

To get any code into the build system it must be set up through the source code management options.


Git options
Git options on the configuration page

To configure source code to be cloned from a Git repository the Repository URL must be specified. By default the master branch will be cloned, although this can be adjusted in the Branches to build section. The code will be cloned into the root of the build directory. If your repository requires credentials to access, then please see the credentials page for details on how to supply them.


Advanced options
Subversion options on the configuration page

Subversion configuration is broadly similar to Git. Add the path to the Repository URL box and select credentials if required. The URL does not have to refer to an entire repository; subdirectories such as branches and tags may be used. As with Git, the chosen code is checked out directly into the top level of the build directory.

Build Triggers

By default all jobs can be run manually through the web interface. It is also possible to set jobs up to trigger at regular intervals, or upon code changes.

Trigger options
Build trigger options on the configuration page

Both the Build periodically and Poll SCM options take cron-style syntax to describe the times at which they will run. The build system also supports the following simpler options:

Option Description
@hourly Every hour
@daily Every day
@weekly Every week

You can also use standard cron-syntax although the symbol H is recommended to help spread the running of jobs.

If Poll SCM is selected but no schedule is entered, the build can be triggered using a post-commit hook - this must be set up in the SCM tool, not Anvil.

Build Environment

These options allow additional customisation of the build process. None of the options are required to be ticked.


Execute shell is the standard build option and should be used in all cases.

Trigger options
Build options on the configuration page

Execute shell

Executing shell code is the standard way to run your build. Any code added to the text area will be executed as a shell script on the build server. It is suggested that you will want to build your code and run any tests as part of this step. For example a standard unix-style tool might have the following build step

module load gcc
make install

Anvil includes a number of different loadable modules containing popular dependencies. These modules are listed on the build software page.

Post-build Actions

Anvil supports a number of post-build options. Tool specific options are described for C++, Fortran and Python.

Post build options
Post-build options on the configuration page

Archive the artefacts

Archiving an artefact marks it for storage after the build is complete so that it can be accessed. Any files can be marked in this way, for example test outputs or redistribution packages. The artefacts can then be accessed though the web interface once the job is complete.

E-mail Notification

Email notifications can be set up and are sent on a build failure and also when a build becomes stable again. Optionally they can also be set to email for every unstable build and to email users mentioned in the commit message of the failed build.