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.
There are a number of basic options which you may want to consider when configuring a freestyle job.
The description can be used to store extra information about the build. This can be particularly useful if the job has multiple administrators.
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.
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.
Very few of the advanced options are generally useful, however you may want to set the 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.
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.
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.
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 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:
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.
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.
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.
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.
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.