Skip to content
This repository has been archived by the owner on Sep 1, 2023. It is now read-only.

0.0.2
Compare
Choose a tag to compare
@adamkewley adamkewley released this 20 Nov 22:27
· 287 commits to master since this release
0.0.2
a385f78

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.

Assets 4
Loading