diff options
Diffstat (limited to '.github/workflows')
-rw-r--r-- | .github/workflows/README.md | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/.github/workflows/README.md b/.github/workflows/README.md new file mode 100644 index 0000000000..ac956f0cf4 --- /dev/null +++ b/.github/workflows/README.md @@ -0,0 +1,40 @@ +## Rationale about our design for the GitHub Actions CI + +The balance is between the time taken and the number of jobs. +We're allowed 180 concurrent jobs in total across the entire project. +Currently we're running about 60 on pull_request, a few more on push and +a pile per day. +So three simultaneous PRs should finish quickly enough. +Given that most jobs run quickly, this could scale up to 5 or 6 without +problem. + +Moving more jobs into the `pull_request` category will limit the number +of parallel builds (from different PRs) we can handle. +We got into quite some strife over this with our older CI hosts +-- remember builds taking the best part of a day to run. +We really want to avoid that again. + +I've been trying to limit total job time per job to around 20-30 minutes +(there are some longer ones I know of), with most jobs running in the +sub 5 minute range. +There are some longer lived CIs -- up to an hour and I try to delegate +these to push or daily rather than pull_request. + +Still, there is no hard and fast rule about what runs when or where. +Make a suggestion about bettering the CIs -- Ideally I'd like the +`pull_request` jobs to be the ones catching most of the problems and the +push and daily being predictably boring successes. +Just make an effort to rationally justify the inclusions/changes. + +Things like the sanitiser builds, we know catch problems often. +So even though they are slow they are worthwhile on `pull_request`. +A lot of the daily builds are unlikely to catch much since they are +checking options can be turned off and on, so they are fine not running +as much. +The demarkation between `pull_request` and `pull_request + push` is the +difficult choice. +I believe we should do all pull_request jobs as part of push too. +The question is how many more should there be. + +I don't have a good answer but I think we're converging on a practical +number and we should get better as we gain experience. |