CI services typically have a per-job timeout parameter that saves compute resources from being wasted. Overall CI system performance is improved by abandoning jobs taking an unexpectedly long time to run. A typical CI experience is that during busy times, certain tasks like downloading can take much 10x or more longer than usual. A balance is struck between expected task time and timeout limit.

repository install

The apt install or brew install operations that access a remote repository are often run in CI tasks. These tasks might take 10-30 seconds normally, but during heavy CI use times they may take about 10 minutes. This makes setting timeouts less intuitive with jobs that only take a few minutes or less build / test time. Empirically, we find with GitHub Actions that making the overall job timeout 15 minutes or so allows for the sometimes 10 minutes peak download time tolerable.

jobs:

  linux:
    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
    - uses: actions/checkout

    - name: install prereqs
      run: |
        sudo apt update
        sudo apt install ninja-build        

    - run: ...

Python pip

We often set a “pip” timeout of 1 or 2 minutes to ensure the CI is using wheels instead of compiling from source, which can take tens of minutes or fail. A job-level timeout can likewise be set.

In this case, rather than setting a job-level timeout-minutes: 6, we know pip for this project takes much less than 1 minute, so we only have to wait one minute if pip goes awry. This becomes important for projects with lots of CI jobs and workflows, you don’t want to have to manually wade through hundreds or thousands of error messages.

jobs:

  linux:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
    - uses: actions/checkout
    - uses: actions/setup-python
      with:
        python-version: '3.x'

    - run: python -m pip install .[tests]
      timeout-minutes: 1

    - run: pytest
      timeout-minutes: 5