Skip to content

Update the routing logic based on recent changes #9307

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Merged
merged 12 commits into from
Sep 3, 2021
Original file line number Diff line number Diff line change
Expand Up @@ -70,9 +70,17 @@ These labels operate cumulatively, so a self-hosted runner’s labels must match

When routing a job to a self-hosted runner, {% data variables.product.prodname_dotcom %} looks for a runner that matches the job's `runs-on` labels:

1. {% data variables.product.prodname_dotcom %} first searches for a runner at the repository level, then at the organization level{% ifversion ghes or ghae %}, then at the enterprise level{% endif %}.
{% ifversion fpt or ghes > 3.2 or ghae-next %}
- {% data variables.product.prodname_dotcom %} first searches for an online and idle runner at the repository level, then at the organization level, {% ifversion fpt %} and if the organization is part of an enterprise,{% endif %} then at the enterprise level.
- If {% data variables.product.prodname_dotcom %} finds an online and idle runner at a certain level that matches the job's `runs-on` labels, the job is then assigned and sent to the runner.
- If the runner doesn't pick up the assigned job within 60 seconds, the job is queued at all levels and waits for a matching runner from any level to come online and pick up the job.
- If {% data variables.product.prodname_dotcom %} doesn't find an online and idle runner at any level, the job is queued to all levels and waits for a matching runner from any level to come online and pick up the job.
- If the job remains queued for more than 24 hours, the job will fail.
{% else %}
1. {% data variables.product.prodname_dotcom %} first searches for a runner at the repository level, then at the organization level, then at the enterprise level.
2. The job is then sent to the first matching runner that is online and idle.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{% data variables.product.prodname_dotcom %} first searches for an online and enabled runner at the repository level, then at the organization level{% ifversion ghes or ghae %}, then at the enterprise level{% endif %}.

  • If we don't find an online and enabled runner at any level, the job is queued to all levels and wait for any runner from any level to come online and pickup the job.
    • If the job remains queued for more than 24 hours, the job will fail.
  • If we find an online and enabled runner (preferred runner) at a certain level, the job is then sent to the preferred runner.
    • 60 seconds after sending the job, if the job is not picked up by the preferred runner, we will try to send the same job to all other levels as well.
    • If the job remains queued for more than 24 hours, the job will fail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @TingluoHuang, I've updated the draft accordingly ⚡

- If all matching online runners are busy, the job will queue at the level with the highest number of matching online runners.
- If all matching runners are offline, the job will queue at the level with the highest number of matching offline runners.
- If there are no matching runners at any level, the job will fail.
- If the job remains queued for more than 24 hours, the job will fail.
{% endif %}