This allow for changing the timeout from the configuration file. If not
set, the default value is 1h. It has the added advantage to not take
into account the docker base image build time.
Details
Details
- Reviewers
jasonbcox - Group Reviewers
Restricted Project - Commits
- rABCd870000060bd: [CI] Set build timeout in the configuration file
Set some short value and run the build. Check the process is killed as
expected after the timeout expired.
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- ci_timeout
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Event Timeline
| contrib/teamcity/build-configurations.json | ||
|---|---|---|
| 4 ↗ | (On Diff #21712) | These units would be much easier to reason about if they were in minutes. It would be very rare for the number of exact seconds to matter in a build timeout, and builds that take hours/days will likely require a change in approach. |
| contrib/teamcity/build-configurations.py | ||
| 16 ↗ | (On Diff #21712) | If this value is not set, I don't think holding up the build agents for 12 hours is a good default. We currently use 1 hour as the default on CI for this reason. Another way to think about it: If a build with default settings runs for many hours, wouldn't you want the CI scream at you for it? |
| contrib/teamcity/build-configurations.json | ||
|---|---|---|
| 4 ↗ | (On Diff #21712) | Since I cannot set a unit with the json format without adding some string parsing work I prefer to keep using the default unit everybody is used to work with when it comes to time. Defaulting to minutes would just be very confusing, and dividing by 60 is not that complicated :) |
| contrib/teamcity/build-configurations.py | ||
| 16 ↗ | (On Diff #21712) | I wanted something absurdly large in order to mean "no timeout if none is given", but I guess it makes sense to use something more reasonable since they are all overridden anyway. |