0.0.7: Made server ignore blank lines in users file

 Please enter a commit message to explain why this merge is necessary,

0.0.6: Various bugfixes

- Fixed a bug where server would keep files open after opening job outputs,
  which would result in a gradual resource leak
- Fixed the job queue such that it dequeues as many jobs as possible (below
  the configuration-defined upper limit) once a running job finishes (previously:
  advancing only happened on submission, which was a bug).

0.0.5: No functional changes from 0.0.4 - this version is entirely to fix CI

issues.

(0.0.4) Several non-breaking development improvements:

- Jobson releases now automatically build & deploys from via Travis CI

- Various system tests have been created for the Jobson CLI. Tests
  will now run various jobson commands (e.g. `jobson new --demo`) to
  ensure they behave as expected.

- All dependencies have been updated to their latest versions

- Redundant dependencies were removed

0.0.3: Non-breaking patch release

• Fixed a bug where downloading larger (over 1 GiB) job outputs would cause CPU and memory spikes because the HTTP server (Jetty) would attempt to gzip it on the way out.

• maxConcurrentJobs and delayBeforeForciblyKillingJobs may now be set in Jobson's server config under an execution: key (generate a new workspace to see an example).

execution:

  maxConcurrentJobs: 10
  delayBeforeForciblyKillingJobs: PT3S  # ISO 8601

• The delayBeforeForciblyKillingJobs indicates how long Jobson should wait after sending a SIGTERM to a process before sending a SIGKILL (if it isn't dead yet)

• Job specs are now returned from the API sorted by name (previously, they were effectively unsorted).

0.0.2

0.0.2: Several (BREAKING) improvements to output handling:

• An stderr/stdout file will not be written to disk until the first byte is written to disk. This prevents the "Empty Output" from appearing in UIs. For example, if nothing has been written to stdout, then a call to /v1/jobs/{job-id}/stdout will return a 404 (previously, it was returning an empty file, which was ambiguous)

• BREAKING API CHANGE: Changed the job outputs HTTP API entrypoint (/v1/jobs/{job-id}/outputs)). The entrypoint now returns a response containing an array of job outputs (previously, it returned an object containing outputs). This change was made so that the order of outputs from a job matches entries in the new (also changed) job spec for outputs. Developers can now stipulate the order in which outputs appear. Moving the entries "one level down" into .entries (rather than just returning an array) was done for forward-compatability with REST links etc.

• A job output in /v1/jobs/{job-id}/outputs now also contains the size of the output in bytes (aptly named .sizeInBytes). This information is useful for downstream clients (rendering decisions, putting the size in download links, etc.)

• BREAKING SPEC CHANGE: Renamed outputs in the spec files to expectedOutputs to offer some symmetry with expectedInputs and to make it clear to developers (and the codebase) that the entries
  are a statement of intention ("I expect these outputs) rather than assertion (these are the outputs).

• BREAKING SPEC CHANGE: The expectedOutputs are now an array of expected output entries. Previously, it was an object with outputId for the key and the expectedOutput details for the value.

• BREAKING SPEC CHANGE: An expectedOutput entry in expectedOutputs must provide an id field (previously, this was taken as the key in the object layout). The ID field is propagated to the job outputs API.

• id may be a template string, following the same rules as template strings in arguments. For example, developers may stipulate that an output has an id of ${request.id}_results.tar.gz`, which will put the request ID into the output filename (this is useful for clients, because it means if they download results from multiple
  jobs those results won't all have the same name and be confusing to work with).

• name was added as an optional field to expectedOutputs. This allows developers to set a human-readable name for the output. The name is propagated to the job outputs API.

• description was added as an optional field to expectedOutputs. This allows developers to set a human-readable description for the output. The description is propagated to the job outputs API.

• metadata was added as an optional field to expectedOutputs. This string-key, string-value object is guaranteed to be left unused by Jobson itself. However, it will be propagated through the job output API, so downstream clients (e.g. UIs) may use it for rendering hints without worrying about whether Jobson will manipulate the value in later versions.

Initial stable release of Jobson

A fully-working initial release of Jobson:

• This version is used internally in a production system with no issues
• Requires a java8 runtime environment (e.g. openjdk-8-jre in debian)
• The attached binaries can be unzipped into any folder and ran locally (e.g. ./jobson new --demo)
• The attached .deb can be used to straightforwardly install it on debian hosts. Beware: This is a quick n' dirty package implementation.
• If you need to package the binaries for other distros, I would personally use fpm (change deb for your desired output):

#!/bin/bash

VERSION=$1

tar -xf jobson-$VERSION-bin.tar.gz

cat <<EOF > jobson
#!/bin/bash

java -jar '/usr/share/java/jobson-$VERSION.jar' "\$@"
EOF

chmod 755 jobson

fpm \
    --force \
    --input-type dir \
    --output-type deb \
    --name jobson \
    --version $VERSION \
    --depends "openjdk-8-jre" \
    --maintainer "Adam Kewley <[email protected]>" \
    --url "https://github.com/adamkewley/jobson" \
    --description "Webify command-line applications" \
    --license "Apache-2.0" \
    jobson-$VERSION/jobson-$VERSION.jar=/usr/share/java/jobson-$VERSION.jar \
    ./jobson=/usr/bin/jobson