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.
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: ...
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