|
|
|
@ -1010,6 +1010,29 @@ existing parsers for most of the programming languages and it is easy enough to
|
|
|
|
|
learn and understand. Another choice which make sense is JSON but at the end
|
|
|
|
|
YAML seemed to be better.
|
|
|
|
|
|
|
|
|
|
#### Task Types
|
|
|
|
|
|
|
|
|
|
From the low-level point of view there are only two types of tasks in the job.
|
|
|
|
|
First ones are doing some internal operation which should work on all platforms
|
|
|
|
|
or operating systems same way. Second type of tasks are external ones which are
|
|
|
|
|
executing external binary.
|
|
|
|
|
|
|
|
|
|
Internal tasks should handle at least these operations:
|
|
|
|
|
|
|
|
|
|
- *fetch* -- fetch single file from fileserver
|
|
|
|
|
- *copy* -- copy file between directories
|
|
|
|
|
- *remove* -- remove single file or folder
|
|
|
|
|
- *extract* -- extract files from downloaded archive
|
|
|
|
|
|
|
|
|
|
These internal operations are essential but many more can be eventually
|
|
|
|
|
implemented. Full list should be accessible in 'Job configuration' appendix.
|
|
|
|
|
|
|
|
|
|
External tasks executing external binary should be optionally runnable in
|
|
|
|
|
sandbox. But for security sake there is no reason to execute them outside of
|
|
|
|
|
sandbox. So all external tasks are executed within sandbox which should be
|
|
|
|
|
general and configurable. Configuration options for sandboxes will be called
|
|
|
|
|
limits and there can be specified for example time or memory limits.
|
|
|
|
|
|
|
|
|
|
#### Configuration File Content
|
|
|
|
|
|
|
|
|
|
@todo: discuss what should be in configuration: limits, dependencies, priorities... whatever
|
|
|
|
|