Boot — (boot (exec))

flyboarder
degree9
Published in
2 min readFeb 28, 2018
Boot Logo

Recently our degree9/boot-exec package hit 1800 downloads, as a build-tooling helper, we are excited to be a part of so many projects!

boot-exec has the simple job of running external processes as part of a boot build pipeline in either a blocking/non-blocking way.

This package is in use by a collection of other boot tasks:

The primary task used within this package is exec which will provide blocking execution of an external process. It is most commonly used by another task to simplify running a specific build tool like npm or a preprocessor such aslessc.

Under the hood we are using the fantastic Apache Commons Exec library, which is written for the JVM.

At the bare minimum the exec task requires a process to be specified.

(exec :process "git")

In most cases we assume your are running on a *nix operating system, however there are some mechanisms in place for Windows support as well.

The location of the process is usually determined for you, however if needed you can specify your own local or global path to the executable.

(exec :process "bower" :local "./")(exec :process "bower" :global "/usr/local/bin")

This is most useful when running things from within a node_modules folder.

(exec :process "npm" :local "node_modules/npm/bin")

In almost all cases you will want to pass additional parameters to your external build tools, this is supported by passing a vector of arguments as strings.

(exec :process "node" :arguments ["app.js"])

By default the exec task generates a temporary directory to run the external process in, this means any files the build tool generates need to be added to the boot fileset.

(exec :process "npm" :arguments ["install"] :include true)

The working directory can be filtered for a subset of the files using exclude .

(exec :process "npm" :arguments ["install"] :include true :exclude #{"node_modules/*.html"})

Custom directories are supported as well as cached directories, which is useful for tools which provide management features and need to operate on the project itself; a great example of this is git .

(exec :process "git" :arguments ["status"] :directory ".")

Finally there is the option to halt the entire build if an external process returns a non-zero exit code.

(exec :process "exit" :arguments ["1"] :fail true)

--

--