Assumptions may be broken by the drastic performance improvement gained from the enhanced runner and the Intelligent Cache. Some common scenarios are:

• Service not ready when used
• Increased flaky test result

Service 

Since jobs startup substantially faster, services may not have enough time to become healthy before use is attempted. To combat this, a health check needs to be added before use. A check can either be added into the job itself or using the built-in HEALTHCHECK_TCP_PORT variable. The built-in check will block execution of the script until the health check passes.

job:
  services:
    - name: postgres
      variables:
        HEALTHCHECK_TCP_PORT: 5432
  script: psql ...

It can be useful to control the health check directly. This allows complex conditions to be checked or startup tasks to be performed before waiting on the health check.

job:
  services:
    - name: postgres
  script: |
    ./build
    ./health-check
    psql ...

Test 

Test failures can be caused by all sorts of things, but in relation to Cedar CI they are generally the fault of pre-existing race-conditions. Such races cause flaky results, but the rate of failure may be aggravated by a change in performance.

For example, database insertions may execute faster and impact a timestamp that causes non-deterministic sorting in a select query. A test depending on the order may thus break.

Another common scenario is concurrent execution of tests that share some global state. Faster execution can change which tests overlap at runtime and thus agitate a race-condition.