** 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.
@@ -61,10 +61,13 @@ Data is synchronised and organised into discrete frames that are represented by
#### 3.1 General Rules
***3.1.1** Non-owner receive state storage for `persistent` data is separate and different from send state as maintained by owners.
***3.1.2** One instance of `Feed`*owns* a given `Frame` id, including across a network.
***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 `persistent` and `transient` modes.
#### 3.2 General Protocol
***3.2.1** Received changes are marked as changes in the corresponding `Frame`.
***3.2.1** Received changes are marked as changes in the corresponding `Frame` being formed.
***3.2.2** A dispatched `Frame` is marked as `flushed`.
***3.2.3** A created `Frame` is not marked as `flushed`.
#### 3.3 Owner Protocol
***3.3.1** Received changes do not result in a dispatch event.
