Exporter Script Server

Exposes configured exporter / validation scripts over HTTP.

Usage

In Script Container

Standard Use

Custom Use

To create a custom setup not based on the demo container, this server can be configured by performing the following steps.

Currently, this server app only supports linux & mac environments.

Download the latest release from the releases page and unpack the archive in your project directory.
Run the command ./service gen-config to generate a server configuration template file. This file will be named config.tpl.yml.
Edit the configuration file with your desired service name and command configurations.

Check the {file-config-readme}[config file readme] for more information about the configuration file.
Once you have edited the configuration file, rename it and place it in the desired relative to the service binary.
Validate the configuration by running the command ./service check-config --config=path/to/your/config.yml. This command will validate the configuration and report any errors.
Bad Config Example
```
$ ./service --config=config.yml check-config
```

Config File

Components

config.yml

1
2
3
4
5 service-name: my service (1)
command:
  executable: /some/path/to/your/executable (2)
  args: (3)
    - <<input-files>> (4)

The display name of the running service

Path to an executable script or binary to be called by the server to process uploaded datasets.

An array of arguments that will be passed to the configured executable. Each array element is effectively a single, quote wrapped cli arg.

Space separated entries in the args array will be treated as a single argument.

An Injected Variable

Command Context

The configured command will be executed in an isolated subshell, but will be provided the same environment as the server itself, meaning it is possible to set environment variables for the script simply by setting them on the docker container.

The output of the script’s stdout will be piped through the server’s logging mechanism and will appear in the container logs.

The output of the script’s stderr will be both piped through the server’s logging mechanism (like stdout) but will also be captured for parsing and returning to the caller.

Variables

`<<cwd>>`

The working directory for the job that is running in the current request.

Example

/workspace/12345

`<<date>>`

The current date formatted as YYYY-MM-DD.

Example

1994-02-13

`<<date-time>>`

The current datetime in RFC3339 format.

Example

2018-10-31T23:37:18.013557+0500

`<<ds-description>>`

The user provided description for the current dataset upload.

Example

My dataset upload containing foo and bar

`<<ds-name>>`

The user provided name for the current dataset upload.

Example

My Dataset 3

`<<ds-summary>>`

The user provided summary of the current dataset upload.

Example

Some summary text for my dataset upload

`<<ds-origin>>`

The source/origin of the user dataset should be either galaxy or direct-upload.

Example

direct-upload

`<<ds-user-id>>`

WDK user ID of the user that uploaded the dataset.

Example

`<<input-files>>`

A space separated list of the files that were unpacked from the uploaded zip or tar file sorted by name ascending.

Examples

Upload Contents

dataset.tgz
 ├─ foo.txt
 ├─ bar.xml
 ├─ fizz.json
 └─ buzz/
     └─ fazz.yml

<<input-files>>

bar.xml buzz fizz.json foo.txt

`<<input-files[n]>>`

Array style access of the input file list allowing retrieval of a single file name from the input file list.

Examples

These use this example input.

<<input-files[0]>>

bar.xml

<<input-files[2]>>

fizz.json

`<<time>>`

The current time formatted as HH:MM:SS.

Example

03:47:58

`<<timestamp>>`

The current unix timestamp in seconds.

Example

783647299