Version 0.4 has been released.
Suspense
This releases adds support for suspending executions. Suspense is a way of putting the step to sleep - the current execution will be stopped and a new execution will be started from the beginning. The suspense is either explicit (by specifying a delay, or a time in the future at which to restart), or implicit (by specifying a timeout for how long to wait for results from dependent executions) - in the latter case, the execution will be automtically restarted (from the beginning) once the dependency has completed and the required result is available. See the documentation for details.
Pausing environments
An environment can be quickly paused (and unpaused) with a single click. Pausing will prevent any new executions from being scheduled (but existing executions will complete).
Cache improvements
Cache keys are now calculated on the server, rather than the client. This means that caching of workflows is more intuitive. You can still specify specific task/workflow parameters to be considered for caching. See the documentation for details.
Additionally, support for specifying a 'cache version' has been added, making it easy to invalidate the cache when, for example, the implementation of a task is updated.
Explicit registration
Until now, agents have published the workflows (and targets) that they provide to the server every time they connect. With this release, registration becomes a separate explicit step (and no longer publishes workflows). This means registration can happen as part of a CI-based release process.
The agent can still be configured to automatically register when it starts (or restarts), by specifying the --register
flag, or by specifying the --dev
flag (which is equivalent to specifying both --register
and --reload
).
Experimental features
A couple of experimental features have been added. One is to support previewing of the contents of directory assets within the UI - this enables creation of richer HTML output. Another is initial support for a 'pools' feature, which provides a mechanism for the server to start compute (currently only local Docker containers) to fulfill demand). Documentation for these features will be added as they mature.