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 on the configuration page
Description
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 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
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.
SVN
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.
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.
Build
Execute shell is the standard build option and should be used in most cases.
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
./configure
make
make install
Anvil includes a number of different loadable modules containing popular dependencies. These modules are listed on the build software page.
Run SLURM script
This will allow you to submit a script to SCARF. See Run jobs on HPC for details.
Post-build Actions
Anvil supports a number of post-build options. Tool specific options are described for C++, Fortran and Python.
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.