Actions: Self-hosted runner

[rjudin]

Thanks to https://github.com/github/roadmap/issues/73 we can create GithubAction groups with self-hosted runners

Expected Behavior

Define self-hosted runners in terraform, based on API ref [1]

Actual Behavior

lack of this possibility [1]

Steps to Reproduce

1. create new Github Org
2. go to https://github.com/organizations/MY_ORG/settings/actions and add a new group by specifying repo scope
3. Add a new runner with labels to this group [2]
4. Execute Action with this group [3]

Proposed resources:

# add group [4]
github_actions_runner_group "dev" {
  description             = "DEV self-hosted runner group"
  name                    = "dev-runners"
  visibility              = "all" #all, selected, or private
  selected_repository_ids = ["repo1.id", "repo2.id"]
  runners                 = [runner1.id, runner2.id] # optional
}

github_actions_runner "dev_win" {
  description = "DEV self-hosted runners with Windows"
  name        = "dev-runners-win"
  labels      = ["dev", "win"]
}

resource "kubernetes_deployment" "dev_win" {
  ...
  env {
    GH_TOKEN = github_actions_runner.dev_win.token
  }
}

References

[1] https://docs.github.com/en/rest/reference/actions [2] https://docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners [3] https://docs.github.com/en/actions/hosting-your-own-runners/using-self-hosted-runners-in-a-workflow [4] https://docs.github.com/en/rest/reference/actions#create-a-self-hosted-runner-group-for-an-organization

[sharebear]

Given that the token for registering a github runner is both single use and time restricted, how do you see this being useful in a larger configuration? Once you have instanciated the runner the first time, any token remaining in the state would be unusable.

I'm currently thinking that I need to go down this route instead https://040code.github.io/2020/05/25/scaling-selfhosted-action-runners but if anyone has a simpler suggestion I'm definitely interested.

[simongottschlag]

An idea is to attach the lifecycle of this resource to something else, like a virtual machine.

As long as the virtual machine isn't recreated, the token doesn't have to be recreated. If the virtual machine is recreated, the same goes for the token.

Would also be nice to be able to choose the scope of the token (repo or org).

Thoughts? 💭

[yann-soubeyrand]

Hello,

Here are my thoughts on this topic:

When a github_actions_runner resource is created, it would create a token (I agree the scope of the token should be configurable), which one can pass to another resource creating the virtual machine powering the runner. The github_actions_runner would then poll GitHub API until the runner is actually there. Once this is the case, the resource would be marked as created, not before. This way, if the virtual machine creation fails, the github_actions_runner would be recreated during the next apply and a new token would be issued. The same would happen if the runner is unregistered from the virtual machine before the machine is destroyed (in a deprovisioner for example). Therefore, the cases where you would have to taint the github_actions_runner would be rare.

I’m really not fond of the polling, though. This is clearly not an elegant solution.

What do you think?

[yann-soubeyrand]

Also, we could well decide that one has to accomodate the fact that a taint on this resource is required in case the runner has to be recreated.

[yann-soubeyrand]

To solve a similar problem, Rancher Terraform provider has two resources for Rancher hosts:

• A rancher_registration_token resource calls the API to create a registration token.
• A rancher_host resource polls the API until the host is registered. When it’s deleted, this resource calls the API to delete the host.

We could use the same paradigm:

• A github_actions_runner_registration_token resource would call the API to create the registration token. To avoid having to taint the resource to create a new token, this resource could have an id argument which would trigger a resource re-creation when its value is changed.
• A github_actions_runner resource would poll the API until the runner is effectively registered. The deletion of this resource would call the API to remove the runner.

[jcudit]

I like the direction this is headed in so far. Excited to see where this goes ❤️

[peimanja]

Can we start with github_actions_runner_group ? We manage self-hosted runners by actions-runner-controller and we can just pass the group they need to register with. so we want to be able to at least manage runner groups with this provider

[yann-soubeyrand]

I didn’t have the time yet to fully complete what I’d like to do, but here’s code that has been waiting on my computer for too long: https://github.com/integrations/terraform-provider-github/pull/1390.

[github-actions[bot]]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[rjudin]

Unstale

[WDaan]

Creating Github hosted runners would be nice as well, not sure if that would be in scope for this one