# Runners

**GitHub Runners**, GitHub Actions iş akışlarının (workflow’ların) **hangi makine/ortam** üzerinde çalışacağını belirler. Yani, bir job çalıştırıldığında aslında “runner” adı verilen bir sunucu ya da bilgisayar (sanal ortam) üzerinde adım adım komutların yürütülmesi gerçekleşir.

### 1) Runner Seçimi: `runs-on`

* YAML dosyanda `jobs.<job_id>.runs-on: <runner_type>` şeklinde belirttiğin kısım, job’un hangi işletim sistemi / ortamda çalışacağına karar verir.
  * Örnek: `runs-on: ubuntu-latest`, `runs-on: windows-latest`, `runs-on: macos-latest`

```yaml
name: Multi-label example
on: [push]

jobs:
  build-linux-x64:
    runs-on:
      - self-hosted
      - linux
      - x64
    steps:
      - name: Build
        run: echo "Building on a self-hosted runner that is Linux and x64"
```

* İstersen bir liste (array) olarak da verebilirsin. Ancak bu durumda runner, listedeki tüm etiketlere uyan bir runner bulmalıdır. (Örneğin `[self-hosted, linux, x64]` gibi.)

### 2) GitHub-Hosted Runner

* **GitHub’ın sağladığı hazır ortamlar**dır. Sen `ubuntu-latest`, `windows-latest` gibi bir değer yazdığında, GitHub senin için otomatik olarak bir sanal makine oluşturur, iş akışı bittiğinde de o makineyi kapatır.
* Avantajları:
  * **Kurulum / bakım gerektirmez**. Tüm yönetimi GitHub yapar.
  * **Otomatik ölçeklendirir** (scaling): Talep arttığında yeni makineler ayarlayabilir.
  * **Üç ana işletim sistemi** (Ubuntu, Windows, macOS) varyantlarını sunar.
* Dezavantajları:
  * Konfigürasyon ve işletim sistemi üzerinde kısıtlı kontrolün var. (Örneğin, root erişimi var ama custom kernel vb. kısıtlı.)
  * Kullanım limitleri (dakika/ay) veya ek ücretlendirmeler olabilir (özellikle özel planlarda).
  * Ortam paylaşımlı olduğundan, bazen belirli güvenlik / IP adresi / özel network ihtiyaçlarında sınırlamalar olabilir.

### 3) Self-Hosted Runner

* **Kendi sunucun** (fiziksel makine, VM, hatta Raspberry Pi vb.) üzerine GitHub Actions runner uygulamasını kurarsın. Bu makine GitHub ile haberleşir ve Actions iş akışlarını orada çalıştırırsın.
* Avantajları:
  * **Tam denetim**: Kullanacağın donanım, yazılım, OS sürümü tamamen sana bağlı.
  * **Özel ağ / veri tabanlarına** doğrudan erişim: Şirket içi kaynaklara ya da izole bir ağa erişmek istiyorsan, bu runner’ı o ağa koyabilirsin.
  * Performansını, bellek, disk, CPU gibi kaynakları istediğin gibi ölçeklendirebilirsin.
* Dezavantajları:
  * **Bakım ve güvenlik** sorumluluğu sende. Makinenin güncellenmesi, güvenlik yamaları vb. senin görevin.
  * GitHub, o makineyi yönetmiyor; yani ek kapasite gerektiğinde otomatik oluşturmaz. Kendin ayarlamak zorundasın.

### 4) Standart Boyut vs. Larger Runners (GitHub-Hosted)

* **Standart Boyut**: Ücretsiz planların sunduğu normal sanal makineler. Normal bellek/CPU kaynaklarıyla gelirler.
* **Larger** (daha büyük makineler) veya “premium” runner seçenekleri, Team ya da Enterprise planlarda sunulur. Daha fazla RAM, CPU, disk alanı, sabit IP gibi özellikleri olabilir.
  * Büyük runner’lar genelde **yüksek kaynak** isteyen (çok parallel testler, büyük build’lar vb.) projelerde kullanılır.

### 5) Koşullar, Kotalar ve Özelleştirme

* **Koşullar / Kotalar**:
  * GitHub Hosted Runner’larda dakikalık kullanım limitin olabilir (ücretsiz planlarda sınırlı, ücretli planlarda daha yüksek).
  * Self-hosted runner’da GitHub’ın dakika limiti yoktur; ama kendi altyapı maliyetin devreye girer.
* **Özelleştirme**:
  * GitHub Hosted Runner’lar “hazır” ortamda belirli yazılımlar (Node, Python, Java, vs.) kurulu gelir.
  * Self-hosted ise tamamen istediğin yazılımı / sürümü kurmakta özgürsün.

#### Özetle,

* **GitHub-Hosted**: Kolay kurulum, anında ölçeklendirme, üç temel işletim sistemine destek, paylaşımlı/standart ortamlara uygun.
* **Self-Hosted**: Tüm kontrol ve bakım sende; özel ağ, özel donanım ve ihtiyaçlar varsa ideal.

Workflow’larda “**`runs-on: ubuntu-latest`**” ya da “**`runs-on: self-hosted`**” diyerek job’un hangi runner’da çalışacağını belirliyorsun. İhtiyacına ve projenin gereksinimlerine göre bu seçimi yaparsın.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://note.onurbolatoglu.com/github-actions/runners.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.