Upstream, downstream, different types of runners#
Depending where an event (e.g. pull request, push, etc.) is raised in our CI, different things will happen
event |
location |
runner type |
comments |
|---|---|---|---|
push/pull-request |
simplecore-tools |
self-hosted |
triggers a build |
pull request |
any other layer repo |
support |
triggers a build in simplecore-tools and waits for completion |
push |
any other layer repo |
cloud |
triggers a build in simplecore-tools |
If an event performs the action within the same repository we will speak of upstream.
Is the action performed in another repository we call it downstream.
The different types of runners can be described like
self-hosted#
Our powerful cloud VMs to perform bitbake builds. Those include a shared cache for sstate, download and build artifacts.
the number of them is limited
jobs are queued by the first-come-first-served principal
support#
Small always-on cloud VMs to handle (potentially) long running downstream job. This helps us to monitor downstream jobs beyond the 6 hour limit (see Github timeouts).
the number of them is limited, so with many events in parallel it could take a moment before a job is picked up
jobs are queued by the first-come-first-served principal
cloud#
Cloud runners are provided by Github and can be spawned in an unlimited number, but they come with very limited hardware specification and have a strict 6 hour runtime limit.