** Notice: all internal pipelines have been restricted to 30 minute timeouts, if your CI/CD runs take longer, either use your own runners or read below **
We would remind everyone that the CI/CD services provided by the university Gitlab servers are intended for CI/CD use only (ie. delivering new versions of your software to your production servers, etc).They are not intended for data analysis or -production use, or creating, building and running servers to do heavy data calculation or visualization.
As a general guideline; if your jobs take more than 15 minutes, you might be running something that is better suited for a dedicated system or a virtual server - in this case, please contact the helpdesk for a solution to your needs.
@@ -72,7 +72,7 @@ Data is synchronised and organised into discrete frames that are represented by
...
@@ -72,7 +72,7 @@ Data is synchronised and organised into discrete frames that are represented by
***3.1.3** Timestamps of received changes must be less than or equal to the timestamp of subsequently created or dispatched `Frame`s to which they are applied.
***3.1.3** Timestamps of received changes must be less than or equal to the timestamp of subsequently created or dispatched `Frame`s to which they are applied.
***3.1.4** Data channel storage mode is respected, meaning such changes can be overridden and lost for `aggregate` and `transient` modes.
***3.1.4** Data channel storage mode is respected, meaning such changes can be overridden and lost for `aggregate` and `transient` modes.
***3.1.5** Received changes are marked as changes in the corresponding `Frame` being formed.
***3.1.5** Received changes are marked as changes in the corresponding `Frame` being formed.
***3.1.6** A dispatched `Frame` is marked as `flushed`.
***3.1.6** A dispatched `Frame` is marked as `flushed`. [REMOVE]
***3.1.7** A created `Frame` is not marked as `flushed`.
***3.1.7** A created `Frame` is not marked as `flushed`.
***3.1.8** Frames received whilst processing previous `Frame` are merged using storage rules and most recent timestamp.
***3.1.8** Frames received whilst processing previous `Frame` are merged using storage rules and most recent timestamp.
