# Introduction

This documents our strategy for self-hosted GitHub runners.

## What is a Self-Hosted Runner

Self-hosted runners offer more control of hardware, operating system, and software tools than GitHub-hosted runners provide. With self-hosted runners, you can choose to create a custom hardware configuration with more processing power or memory to run larger jobs, install software available on your local network, and choose an operating system not offered by GitHub-hosted runners. Self-hosted runners can be physical, virtual, in a container, on-premises, or in a cloud.

## Differences between GitHub-hosted and self-hosted runners

GitHub-hosted runners:

- Receive automatic updates for the operating system, preinstalled packages and tools, and the self-hosted runner application.
- Are managed and maintained by GitHub.
- Provide a clean instance for every job execution.
- Use free minutes on your GitHub plan, with per-minute rates applied after surpassing the free minutes.

Self-hosted runners:

- Receive automatic updates for the self-hosted runner application only, though you may disable automatic updates of the runner. 
- You are responsible for updating the operating system and all other software.
- Can use cloud services or local machines that you already pay for.
- Are customizable to your hardware, operating system, software, and security requirements.
- Don't need to have a clean instance for every job execution.
- Are free to use with GitHub Actions, but you are responsible for the cost of maintaining your runner machines.

## Seagen Self-Hosted Runner Standards

You can add self-hosted runners at various levels in the management hierarchy:

- Repository-level runners are dedicated to a single repository.
- Organization-level runners can process jobs for multiple repositories in an organization.
- Enterprise-level runners can be assigned to multiple organizations in an enterprise account.

Our standard is to use `Organization-level` runners.  Using them at this level with [runner-groups](https://docs.github.com/en/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups) is a very simple and efficient way to deploy and manage runners.

Supported [operating systems](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#supported-architectures-and-operating-systems-for-self-hosted-runners) for self-hosted runners

- Linux
  - Red Hat Enterprise Linux 7 or later
  - CentOS 7 or later
  - Oracle Linux 7
  - Fedora 29 or later
  - Debian 9 or later
  - Ubuntu 16.04 or later
  - Linux Mint 18 or later
  - openSUSE 15 or later
  - SUSE Enterprise Linux (SLES) 12 SP2 or later

- Windows
  - Windows 7 64-bit
  - Windows 8.1 64-bit
  - Windows 10 64-bit
  - Windows Server 2012 R2 64-bit
  - Windows Server 2016 64-bit
  - Windows Server 2019 64-bit

- macOS
  - macOS 10.13 (High Sierra) or later

Our operating system standard is `Linux`.  OCI will use `Oracle Linux`, all other environments should use `CentOS`

## Other Standards

- All runners should utilize [labels](https://docs.github.com/en/actions/hosting-your-own-runners/using-labels-with-self-hosted-runners)
- All runners should utilize [runner groups](https://docs.github.com/en/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)
- The runner application should be setup as a [service](https://docs.github.com/en/actions/hosting-your-own-runners/configuring-the-self-hosted-runner-application-as-a-service)