The task runner tool executes user defined tasks.
Tasks are recipes for performing typical build and test actions as found on most CI systems. The task runner abstracts those so:
Task files describe:
result
folder)Tasks can be run on the local machine without a CI system running. Example:
$ ./task try hello_world3.sh
We have a special jenkins job running which accepts task submission for one-time execution. Example:
$ ./task submit hello_world3.sh
Tasks can be executed as part of a normal jenkins job. This allows to use jenkins triggers like version control changes or reporting features like sending mails on failures to be used.
-a xxx=yyy
) however work as usual.The corresponding jenkins job should:
${WORKSPACE}/config
config/task jenkinsrun config/hello_world3.sh
Tasks can be executed on a remote machine via ssh without having a CI system installed. Requirements for this to work:
$ ./task sshrun mymachine.local hello_world3.sh
Notes:
username@mymachine.local
to switch user names$HOME/.ssh/config
to configure the ssh connection (see ssh docu)ssh -A
so ssh keys from your local machine are forwarded and available on the remote machine.The task
tool decides what inputs are use for the tasks artifact parameters before starting/submitting a build.
This is usually done by querying the repository definitions in the repos
directory (and repos.try
in some modes). For example for an artifact parameter called llvm
we could have a repos/llvm.json
configuration file to query the latest revision of a git repository:
{ "url": "https://github.com/my-project.git", "type": "git", "default_rev": "refs/heads/master" }
To query the latest artifact from a directory in the A2 artifact server:
{ "url": "http://lab.llvm.org:8080/artifacts/clang-stage1-configure-RA", "type": "artifact_server" }
You can specify an URL to an archive file on the commandline to override the other mechanisms:
$ lnt task try -a compiler=http://my.storage.server/my_compiler.tar.bz2
Tasks files are written as posix shell scripts. The following describes the environment in which they are executed.
hello_world0.sh
up to hello_world3.sh
and hello_param.sh
are considered tutorials. They are simple tasks that are well documented and show more advanced uses with each script.
Scripts execute in an empty directory called workspace:
WORKSPACE
environment variable contains the name of this directory./dev/null
. See hooks/try.sb
for the sandbox definition.A task can have named string and artifact parameters. An artifact is a directory conaining files and subdirectories. Typical artifact sources are git repositories or archives from artifact storage servers.
Artifacts can be queried and extracted into a workspace directory with the same name:
build get ARTIFACT_NAME
To extract an artifact into a directory with a different name use:
build get DIRECTORY_NAME --from=ARTIFACT_NAME
Arguments for string parameters can be queried with:
VARIABLE="$(build get arg PARAMETER_NAME)"
Parameters marked as optional don't need an argument and will then return an empty string:
VARIABLE="$(build get arg --optional PARAMETER_NAME)"
Other default values can be supplied with the usual shell tricks:
: ${VARIABLE:='DefaultValue'}
refs/heads/master
in a git repository or clang-stage2-cmake
on an A2 server are resolved to a concrete git revision or a specific URL when the task is started.task try mytask.sh
resolves artifact inputs and executes a local build.task submit mytask.sh
resolves artifact inputs and submits a build to a queue on a jenkins server.task jenkinsrun mytask.sh
may be used to run the task as part of a recurring jenking project.The task files are part of a version control repository. When running a task this repository is always checked out to a subdirectory named config
. This allows task files to bundle and reference additional files in the repository such as helper scripts shared between multiple tasks.