Closed jimsheldon closed 1 year ago
I started to write a test case which should work at the step level, but not the stage level.
jobs:
cypress-run:
runs-on: ubuntu-20.04
timeout-minutes: 10
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Cypress run
uses: cypress-io/github-action@v2
timeout-minutes: 5
with:
command: npm run expect -- --env lastName=Smith
env:
CYPRESS_firstName: Joe
.golden
name: timeouts
stages:
- name: cypress-run
spec:
clone: {}
platform:
arch: amd64
os: linux
runtime:
spec: {}
type: cloud
steps:
- name: Cypress run
spec:
envs:
CYPRESS_firstName: Joe
uses: cypress-io/github-action@v2
with:
command: npm run expect -- --env lastName=Smith
timeout: 5m
type: action
type: ci
version: 1
Timeout is also supported at the pipeline level, but not the stage level.
v1
options:
timeout: 10m
v0
pipeline:
timeout: 10m
I think we only need to worry about appending m
since timeout-minutes
will only ever be in minutes, but Harness CI supports more based on the docs:
Enter how long you want Harness to try to complete the step before failing and initiating the > stage or step Failure Strategy.
You can use:
w for weeks d for days h for hours m for minutes s for seconds ms for milliseconds The maximum is 53w.
Timeouts can be set at the step level also.
We need to document how our timeout differs from other providers as we add them.
GitHub Actions max workflow duration is 35 days https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits
The maximum number of minutes to let a job run before GitHub automatically cancels it. Default: 360
We will likely need to convert to a string (
30
should probably be30m
), but we will need to verify.See