Multiple Runner Types

[mcaulifn]

It is looking like we will need to support multiple runner types for one implementation. I think the module can be modified to do so, re-using as much of the common pieces as possible without creating a completely separate deployment.

The easiest way would be to do a for_each loop on the runners module call. That would create two sets of scale-up/down lambdas though. It would also require a new input variable defining all aspects of each runner type. If this variable is not set, it would need to be constructed from the existing variables.

Thoughts on this approach?

[npalm]

Fully agree that we need to support multiple runner typs. But preferable tha would be connected to runner tag. The issue today is that github is not seding an event per job, where you use the runs-on tag. In case github is support such kind of event we can easy scale bade on the the tag.

Till that time I see either 2 approachtes:

• Scale per repo, downside is that scaling is not based on a job but for any job in a given repo. This means per type an app, webhook, scale up, scale down.
• Second option would be parsing workflows and find the wokflow and find the job and tag that triggers the job. Next scale based on that information. Rquires much more work. And all the information should already be available interally in the github system.

Looking for more and better suggestions.

[mcaulifn]

I didn't even think about the data the lambda is receiving. Option 1 seems overkill and not worth it. Option 2, finding runs-on, might be easier. But it is not a great long-term solution. Maybe GH is open to adding some data to the post from the webook.

[mcaulifn]

This is messy

1. GET /repos/{owner}/{repo}/check-runs/{check_run_id} returns check_suite['id'] = run_id
2. GET /repos/{owner}/{repo}/actions/runs/{run_id} returns workflow_url
3. GET {workflow_url} returns html_url which is a link to the yaml file

[rvoitenko]

I trying to archive multiple runners types for other reason. Let's say want to have two runners types - m5.large as default on organization level and m5.xlarge for specific repo.
I want to have this second type of runners m5.xlarge not only because higher performance need in some cases, but for security reasons as well. These m5.xlarge runner will have access to prod environment, so they will be placed in separate VPC.

I did experiment a bit and setup two modules, with different instance types(m5.large and m5.xlarge), set different runner_extra_labels and each module connects to it's own github app via webhook.
m5.large module has enable_organization_runners = true and installed for all repos, the github app have read/write permission for org level
m5.xlarge module has enable_organization_runners = false and installed into single repo, the github app have read/write permission for repo level only

For both I've set idle_config to have 1 idle runner during working hours.

However when I run workflow which require m5.xlarge runner, it trigger both github app webhook. And as result lambdas spinup 2 instances - m5.large and m5.xlarge.
I got that check_run doesn't consist runner type in payload.
But is it possible to solve this in GitHub permissions way somehow? Or webhook on app, which has access to org events will be always triggered ?
Anyone knows ?

[npalm]

@rvoitenko At this moment the GItHub api for having multiple types is limitted. We don't install the org level runners by default for all repo's specific to an repo. (Via IssueOps, currently this repo is not open source). And there for scaling is only triggers by those repo's. For repo's that have an own runner, they have a seperated app. This avoids the double scaling.

[rvoitenko]

@npalm just to clarify, you have only one GitHub app which responsible for scaling runner for specific repos.
So currently it's not possible to have two GitHub app with check_run events enabled and prevent double scaling ?

[npalm]

Seems GitHub is working on an event that will sent for every job including the runs-on block. actions/runner#1166

[npalm]

GitHub has a private beta for the new workflow_job event. I have already prepared support for the new event. Once the event is available we could use labels in the event to create different types (#1019)