beat.core issueshttps://gitlab.idiap.ch/beat/beat.core/-/issues2020-10-19T15:16:45Zhttps://gitlab.idiap.ch/beat/beat.core/-/issues/74Update the schemas to better reflect parameter type support in different objects2020-10-19T15:16:45ZJaden DIEFENBAUGHUpdate the schemas to better reflect parameter type support in different objectsSee https://gitlab.idiap.ch/beat/beat.editor/issues/205#note_40301
The issue we found first is that the algorithm editor's parameter logic doesn't actually support complex types, but the algorithm schema indicates support. See the algor...See https://gitlab.idiap.ch/beat/beat.editor/issues/205#note_40301
The issue we found first is that the algorithm editor's parameter logic doesn't actually support complex types, but the algorithm schema indicates support. See the algorithm schema, `algorithm/common.json:80`:
```json
80 "parameter": {
81 "type": "object",
82 "properties": {
83 "type": { "$ref": "../common/1.json#/definitions/basetype" },
84 "default": { "$ref": "../common/1.json#/definitions/value" },
85 "description": { "type": "string" }
86 },
87 "required": [
88 "type"
89 ]
90 },
```
The `type` field references the `basetype` types, which includes complex types, but the editors (`beat.web` & `beat.editor`) don't actually support complex types for algorithm parameters.
I'll be looking through the other schemas and will update this issue with other things I find, if any.
EDIT: didn't find anything else in the other objects' schemas parameter definitionsJaden DIEFENBAUGHJaden DIEFENBAUGHhttps://gitlab.idiap.ch/beat/beat.core/-/issues/56Docker timer tests rely on having adequate CI resources2018-12-12T09:13:59ZJaden DIEFENBAUGHDocker timer tests rely on having adequate CI resourcesSometimes docker timing tests will fail when the tests go too slowly. These tests rely on a hard-coded number of seconds/milliseconds with numbers that are reasonable to assume on one's own machine but obviously aren't designed for a CI ...Sometimes docker timing tests will fail when the tests go too slowly. These tests rely on a hard-coded number of seconds/milliseconds with numbers that are reasonable to assume on one's own machine but obviously aren't designed for a CI (just see the [docker tests](https://gitlab.idiap.ch/beat/beat.core/blob/85cef289db0eac7aaa47308dd92cc5003a6a689b/beat/core/test/test_docker.py).
Some of these tests can just be changed. For example, the `test_images_cache` tests are actually relative tests - you just want to be sure that doing something a second time is faster than the first time. I believe that the CI performance would be consistent across each of these tests (which shouldn't last for more than a couple seconds).
There's other ones though, like the timeout tests. Not sure what to do with those.
This doesn't unconditionally make the CI fail since rerunning the job usually fixes it.