Creating GitHub Actions Workflows

Neden push ve pull_request Olayları?

CI işlem hattımızın ana amacı, kod tabanımıza entegre edilen her değişikliğin projemizi bozmamasını sağlamaktır. Bu nedenle, iki kritik olayda otomatik kontrolleri çalıştırmak isteriz:

1. push: Bir geliştirici, ana geliştirme dallarından birine (main veya develop gibi) yeni kod gönderdiğinde. Bu, dalın her zaman sağlıklı ve çalışır durumda kalmasını sağlar.
2. pull_request: Bir geliştirici, yaptığı değişiklikleri ana dallardan birine birleştirmek için bir çekme isteği oluşturduğunda. Bu, potansiyel olarak hatalı kodun ana dala girmeden önce tespit edilmesini sağlar.

İş Akışı Tetikleyicilerini Tanımlama

Önceki dersten hatırlayacağınız gibi, bir iş akışını neyin tetikleyeceğini on anahtar kelimesiyle belirtiriz. En basit haliyle, hem push hem de pull_request olaylarında çalışacak bir iş akışını şöyle tanımlayabiliriz:

name: CI Pipeline

on: [push, pull_request]

jobs:



  # ... işler buraya gelecek ...

Bu sözdizimi işe yarar, ancak genellikle daha hassas kontrole ihtiyacımız olur. Örneğin, her push olayında değil, sadece main dalına yapılan push'larda çalışmasını isteyebiliriz. Bu tür bir kontrolü sağlamak için daha yapısal bir YAML formatı kullanırız.

Aşağıdaki video, bir iş akışı dosyasının nasıl oluşturulduğunu ve on anahtar kelimesinin push ve pull_request olaylarını nasıl tetiklediğini hızlıca gösteriyor.

push ve pull_request Tetikleyicilerinde Uzmanlaşma

Şimdi, bu tetikleyicileri nasıl daha hassas bir şekilde yapılandırabileceğimizi detaylıca inceleyelim. Bunun için mükemmel bir kaynak olan aşağıdaki makaleyi okumanızı rica ediyorum. Bu makale, push ve pull_request tetikleyicilerini, dal (branch) ve dosya yolu (path) filtrelerini kullanarak nasıl özelleştireceğimizi adım adım anlatıyor.

Okuduğunuz makaleden öğrendiğimiz en önemli noktaları özetleyelim:

push Olayı Filtreleri

push olayını, yalnızca belirli dallara yapılan gönderimlerde tetiklenecek şekilde filtreleyebiliriz.

on:
  push:



    # Sadece 'main' ve 'develop' dallarına yapılan push'larda çalışır.
    branches:
      - main
      - develop

'feature/**' gibi wildcard (joker karakter) desenleri kullanarak feature/ ile başlayan tüm dalları da dahil edebiliriz. Bu, ana dallar dışındaki geliştirme dallarında CI çalıştırmamak için oldukça kullanışlıdır.

pull_request Olayı Filtreleri

pull_request tetikleyicisi, CI için en kritik olanıdır çünkü kod ana dala birleşmeden önce kalite kontrolü sağlar.

Burada dikkat etmeniz gereken iki önemli nokta var:

1. branches Filtresi Hedef Dalı Belirtir: push olayının aksine, pull_request içindeki branches filtresi, çekme isteğinin kaynak dalını değil, hedef dalını (yani kodun birleştirilmek istendiği dalı) belirtir. Bu mantıklıdır, çünkü amacımız main gibi kritik dalları korumaktır.

2. types ile Aktivite Belirtme: pull_request olayı birçok aktiviteyi (açılma, kapanma, etiketlenme vb.) içerir. CI işlem hattımızı genellikle yalnızca kod değiştiğinde çalıştırmak isteriz. Bu yüzden types kullanarak bunu belirtiriz:

   • opened: PR ilk açıldığında.
   • synchronize: PR'a yeni commit'ler eklendiğinde.
   • reopened: Kapatılmış bir PR tekrar açıldığında.

Aşağıdaki görsel, bu yapılandırmaların YAML dosyasında nasıl göründüğünü özetlemektedir:

Pratik Bir CI Tetikleyici Yapılandırması

Şimdi öğrendiklerimizi birleştirelim ve projemiz için tipik bir CI tetikleyici yapılandırması oluşturalım. Amacımız, iş akışımızın aşağıdaki durumlarda çalışmasını sağlamak:

• main dalına doğrudan kod push edildiğinde.
• main dalını hedefleyen bir pull_request açıldığında, güncellendiğinde veya yeniden açıldığında.

Projenizin kök dizininde .github/workflows/ adında bir klasör oluşturun ve içine ci.yml adıyla aşağıdaki dosyayı ekleyin:

# .github/workflows/ci.yml

name: PySpark ETL CI Pipeline

on:



  # 1. main dalına yapılan push'larda çalıştır
  push:
    branches:
      - main




  # 2. main dalını hedefleyen pull request'lerde çalıştır
  pull_request:
    branches:
      - main
    types: [opened, synchronize, reopened]

jobs:



  # Şimdilik sadece tetikleyicinin çalıştığını doğrulayan basit bir iş
  trigger_validation_job:
    runs-on: ubuntu-latest
    steps:
      - name: Print trigger event information
        run: |
          echo "Workflow was triggered by the '${{ github.event_name }}' event."
          echo "The target branch/ref is '${{ github.ref }}'."

Bu yapılandırmadaki trigger_validation_job işi, henüz gerçek testleri çalıştırmıyor. Sadece iş akışının hangi olay (github.event_name) tarafından tetiklendiğini ekrana yazdırarak tetikleyicilerimizin doğru çalışıp çalışmadığını doğrulamamıza yardımcı oluyor. Bu, özellikle karmaşık iş akışları oluştururken hata ayıklama için çok değerli bir tekniktir.

Sonuç

Bu derste, bir GitHub Actions iş akışını en yaygın ve önemli iki olay olan push ve pull_request ile nasıl tetikleyeceğimizi öğrendik.

Temel Çıkarımlar:

• İş akışı tetikleyicileri, .yml dosyasındaki on bloğu altında tanımlanır.
• push olayları için branches filtresi, kodun gönderildiği kaynak dalı kontrol eder.
• pull_request olayları için branches filtresi, kodun birleştirilmek istendiği hedef dalı kontrol eder. Bu kritik bir farktır.
• pull_request tetikleyicisi, types anahtar kelimesi ile (opened, synchronize vb.) hangi PR aktivitelerinde çalışacağını belirleyerek daha verimli hale getirilebilir.

Artık CI işlem hattımızın "ne zaman" çalışacağını tanımlayabiliyoruz.

Gelecek Dersin Önizlemesi:
Tetikleyicilerimiz hazır olduğuna göre, bir sonraki dersimizde iş akışımızın "ne yapacağını" tanımlayacağız. GitHub Actions işimize yeni adımlar ekleyerek Python ortamını kuracak, requirements.txt dosyasındaki bağımlılıkları (PySpark, pytest vb.) yükleyecek ve pytest komutunu çalıştırarak testlerimizi otomatikleştireceğiz.