GitLab

`test` stage is defined by default. No need to specify.
(also job `test` is not the same than stage `test`)

Add `docker` tag to `.gitlab-ci.yml` to ensure CI is runned with docker-enabled
runners.

client: Add mechanism for loading external resources

Closes #11

See merge request !14

runner: replace parallel loading of resources with sequential one

Closes #17

See merge request !13

Add `client/external.js` which load third-party scripts passed into the
`externalLibs` array of the client config object.

The runner would load all the client resource files in parallel, causing errors
intermittently due to some resources depending on other ones.
This behavior was incorrect.

Runner to uses `resolveSequentially` that ensure that each resource is loaded in
order.

client: Add first version of robot behavior

Closes #11

See merge request !12

Implement first version of robot behavior. Currently, the robot listen for new
participants and, when a participant connect, start speech recognition.

The results of speech recognition are displayed in the console.

The robot requires the `start()` method to be called to begin. This method is
automatically called by the runner after loading all the modules.

Add speech-to-text function to hublot client side

Closes #6

See merge request !8

Replace description test with meaningful descriptions

Replace test descriptions 'should not call callback with actual status' with 'should not call callback with incorrect value of status'
Replace test description 'should not call callback with actual final' with 'should not call callback when final value is incorrect'
Replace 'toHaveBeenCalledWith' with 'toHaveBeenCalled()' to test that the callback has not been called at all

lib/controller: ignore test files

Closes #12

See merge request !11

Extract conference participants audio streems, and sending them to Kaldi server to transcription using websockets

`lib/controller` now ignore test files. Not ignoring test files would means that
the runner would try to load them into the client resulting in errors.

Update tests to check this behavior.

Fixes #12.

client config is now set globally via config file

Closes #10

See merge request !10

Client config is now defined in `config.json` and injected by the runner into
the client side.
This allows to pass a single unified config object to each client-side script.

Refactor previous system into this.

Fixes #10

Add editorconfig file

Closes #9

See merge request !9

client: Update controller API

Closes #5

See merge request !7

fixes #9

Add yarn.lock

See merge request !6

Update controller API according to #1

Fixes #5

Configure Continuous Integration

Closes #8

See merge request !5

Add `ci` to define a specific script for continuous integration

Setup config

See merge request !4

Fix package.json

See merge request !3

Fix styling issues identified by xo

use spaces for indent
setup jest env

Use jest for tests monitoring.

Fix a typo in package.json

Implement robot injector mechanism

Closes #7

See merge request !2

We now use the function defined in `lib/controller` to load the resources to
inject into the client.

The order of the "modules" to be loaded is defined as follow:
- controller
- lib
- robot

Each module corresponds to a specific folder in the `client` folder.

This module allow to load all the files that must be injected into the client.

We define three modules to be injected in the client:
- controller: in charge of exposing the hubl.in functions as a unified API
- lib: containing various libraries to be used by the robot
- robot: containing the behavior of the robot itself

Currently these modules only contain the base skeleton.

Instead of a single controller file, `runner.run` now takes a list of source
files that will be injected in the passed order.

- `robotClientController.js` moved to `client/controller/controller.js`
- `controller` renamed to `robotController`
- changed some `var` to `const`
- updated path to controller in `app.js`