GitHub Actions'da iş akışlarını yönetme ve hatalarını ayıklama

Tamamlandı

Amacınızın kod derleme ve yayımlama işlemini otomatikleştirerek geliştiricilerin kod tabanına her değişiklik ekleyişinde özelliklerin güncelleştirilmesi olduğunu hatırlayın.

Bu işlemi uygulamak için şunların nasıl yapılacağını öğrenirsiniz:

  • bir iş akışını tetikleyen olayı belirleyin.
  • GitHub Actions iş akışı günlüklerini kullanın.
  • Yapı çıktıları kaydedin ve bunlara erişin.
  • Gözden geçirmeden sonra çekme isteğine etiket eklemeyi otomatikleştirin.

bir iş akışını tetikleyen olayı tanımlama

GitHub Actions iş akışını tetikleyenleri anlamak, CI/CD işlem hatlarında hata ayıklama, denetim ve iyileştirme açısından çok önemlidir. Tetikleyici türleri arasında bir dalı itme, oluşturulan veya güncellenen bir çekme isteği, zamanlanmış bir iş veya manuel gönderim bulunur. İş akışı çalışmasını, depolardaki değişiklikleri ve ilgili GitHub sorununu veya çekme isteğini inceleyerek tetikleyici olayı tespit edebilirsiniz.

GitHub Actions'ta gönderme, çekme isteği, zamanlama ve el ile gönderme gibi çeşitli iş akışı tetikleyicilerini gösteren diyagram.

İş akışı tetikleyicisi nedir?

İş akışı tetikleyicisi, bir iş akışının çalışmasına neden olan bir olaydır. GitHub, aşağıdakiler dahil olmak üzere çeşitli tetikleyici türlerini destekler:

  • push veya pull_request (kod değişikliklerine göre)
  • workflow_dispatch (el ile tetikleme)
  • schedule (cron görevleri)
  • repository_dispatch (dış sistemler)
  • Sorun, tartışma ve çekme isteği olayları (örneğin, issues.opened, pull_request.closed)

Tetikleyici olayını tanımlama

Bir iş akışı tetikleyici olayını birden çok şekilde tanımlayabilirsiniz:

  • GitHub Actions kullanıcı arabirimini kullanın:

    1. Deponuzda Eylemler sekmesini seçin.
    2. Bir iş akışı çalıştırması seçin.

    İş akışı çalıştırma özetinin en üstünde , pushveya pull_requestgibi workflow_dispatchbir olay türü görüntülenir.

  • Günlüklerde veya iş akışında kullanın github.event_name .

    • GitHub, bir iş akışı çalıştırması sırasında bağlam verilerini kullanıma sunar. github.event_name değişkeni, iş akışını tetikleyen olayı bildirir.

    • Hata ayıklama için bir adımdaki bilgileri yazdırabilirsiniz:

      -name: Show event trigger
        run: echo "Triggered by ${{ github.event_name }}"
      
  • İş akışı yürütme ayrıntılarını kullanın.

    • API kullanarak veya program aracılığıyla iş akışı çalıştırmalarını incelerseniz, çalıştırma nesnesi, tetikleyiciyi belirten bir event özelliğe sahiptir.
    • Bir tetikleyiciye neyin neden olduğunu izlemek için commit Secure Hash Algoritması (SHA), aktör ve zaman damgası bilgilerini bulabilirsiniz.

Tetikleyiciyi depo etkilerinden çıkar

İş akışı çalıştırmasına doğrudan erişiminiz olmayabilir, ancak yine de depo etkinliğine göre iş akışı çalıştırmasını neyin tetiklediğini çıkarsamak istiyorsunuz:

Gözlemlenen davranış Tetikleyici olayı
Yeni bir işleme gönderildi main ve iş akışı başlatıldı. push etkinlik
Bir pull request açıldı veya güncellendi. pull_request etkinlik
Katkıda bulunan manuel olarak bir iş akışı çalıştırdı. workflow_dispatch
İş akışı her gün belirli bir saatte çalışır. schedule (cron)
İş akışı, bir dış hizmet çağrısından sonra çalıştırıldı. repository_dispatch
Bir soruna etiket veya açıklama eklendiğinde iş akışı çalıştırıldı. issues.* etkinlik

Zaman damgalarını, çekme isteği etkinliğini ve işleme geçmişini gözden geçirerek, genellikle iş akışının çalışmasına hangi eylemin neden olduğunu saptayabilirsiniz.

Bir iş akışını tetikleyen şeyin nasıl belirleneceklerini özetlemek için:

  • Eylemler sekmesinde iş akışı çalıştırma özetini denetleyin.
  • İş akışının içinde görünürlük için github.event_name yazdır veya günlüğe kaydet.
  • Tetikleyici belirlemek için zaman damgalarını ve depo faaliyetlerini (işlemeler, çekme istekleri, sorunlar) karşılaştırın.
  • Daha ayrıntılı araştırma için bağlamın tamamını event kullanın.

Bu uygulamalar geliştirme ve dağıtım işlem hatlarınızda iş akışı güvenilirliğini ayıklamanıza, denetlemenize ve geliştirmenize yardımcı olur.

Yapılandırma dosyasını okuyarak bir iş akışı efektini anlama

Bir iş akışının etkilerini anlamak için, .yml içinde depolanan .github/workflows/ dosyasının yapısını ve içeriğini analiz edin.

İş akışı yapılandırma dosyası, iş akışı hakkında aşağıdaki bilgileri belirtir:

  • on bölümünde çalıştığında.
  • Ne yapar (jobs ve steps içinde).
  • Çalıştığı yer (runs-on bölümü).
  • Neden çalışır (amacı, örneğin test etme, dağıtma veya lint etme).
  • Belirli koşullarda (ortam, filtreler, mantık) nasıl davrandığını.

İş akışı efektini yorumlama

  1. Tetikleyiciyi tanımlayın.

    İş akışını başlatan eylemi belirlemek için iş akışının on bölümüne bakın.

    Örneğin:

    on:
      push:
        branches: [main]
      pull_request:
        types: [opened, synchronize]
      workflow_dispatch:
    

    Bu örnek iş akışı:

    • Kod ana dala (push ) gönderildiğinde otomatik olarak çalışır.
    • Çekme isteği oluşturulduğunda veya güncelleştirildiğinde (pull_request) çalışır.
    • Kullanıcı (workflow_dispatch) tarafından el ile tetiklenebilir.
  2. İş akışı işlerini ve adımlarını tanımlama.

    İş akışının ne yaptığını belirlemek için iş akışının jobs ve steps bölümlerine bakın.

    Örneğin:

    jobs:
      test:
        runs-on: ubuntu-latest
        steps:
          - name: Checkout code
            uses: actions/checkout@v3
          - name: Install dependencies
            run: npm install
          - name: Run tests
            run: npm test
    

    Bu örnek iş akışı:

    • Linux sanal ortamı (runs-on) kullanır.
    • Deponun kodunu (steps>name ) denetler.
    • Proje bağımlılıklarını (steps>name) yükler.
    • Otomatikleştirilmiş testleri (steps>name) çalıştırır.
  3. İş akışının amacını ve sonucunu değerlendirin.

    Yapılandırma dosyasını okuyarak iş akışının hedeflenen sonucunu açıklayabilirsiniz:

    "Bu iş akışı sürekli tümleştirme (CI) işlem hattıdır. Depoya gönderilen veya çekme isteği yoluyla gönderilen tüm yeni kodların otomatik olarak test edilmesini sağlar. Testler başarısız olursa GitHub iş akışı kullanıcı arabirimi, kod kalitesini korumanıza yardımcı olmak için bu sonucu görüntüler."

  4. İş akışının çalışma şeklini etkileyen isteğe bağlı özellikleri belirleyin veya ayarlayın:

    • env ortam değişkenlerini ayarlar.
    • if belirli adımları yalnızca ölçütler karşılandığında çalıştırmak için koşullu mantık ekler.
    • timeout-minutes veya continue-on-error iş akışı yürütme ve hata işlemeyi ayarlayın.

Başarısız bir iş akışı çalışmasını tanıla

  1. Deponuzda Eylemler sekmesine gidin.

  2. Başarısız çalıştırmayı bulun (genellikle kırmızı X ile gösterilir).

  3. Çalıştırma özetini açmak için başarısız olan iş akışını seçin.

  4. İş akışı günlüklerinde hatayı gözden geçirin.

    1. Çalıştırma özetinde, başarısızlığı belirten iş veya adımı bulana kadar her bir işi ve adımı genişletin.

    2. Günlükleri görüntülemek için bir işi veya adımı seçin.

    3. Şunu arayın:

      • Hata iletileri
      • Yığın izleri
      • Çıkış kodları

    Örneğin, başarısız bir test npm ERR! Test failed veya exit code 1 gösterebilir.

  5. İş akışı yapılandırma dosyasını denetleyin.

    .yml dosyasını aşağıdakileri belirlemek için kullanın:

    • Her adım ne yapmaya çalışıyordu?
    • Yürütmeyi etkileyen ortam değişkenleri (env) veya koşullular (if) varsa.
    • Hata eksik bir bağımlılık, söz dizimi hatası veya yanlış yapılandırılmış adımdan kaynaklanıyorsa.

    Bir adım başarısız olursa aşağıdaki nedenleri denetleyin:

    • Önceki adımda bağımlılıklar başarıyla yüklendi mi?
    • Test dosyaları var mı ve yerel olarak geçiyor mu?

Yaygın hata senaryoları

Aşağıdaki tabloda yaygın iş akışı hatası senaryoları açıklanmaktadır:

Semptom Olası neden
Bir adım başarısız olur ve command not found l döndürür Eksik bağımlılık veya yanlış kurulum
npm install Başarısız. Bozuk package-lock.json dosya veya ağ sorunu
Test adımı başarısız oluyor Birim testi sorunları, eksik yapılandırma dosyası veya geçersiz test söz dizimi
Permission denied Görünür. Yanlış dosya izinleri veya eksik gizli bilgiler

GitHub'da iş akışı günlüklerine erişmeyi belirleme

  1. Deponuzda Eylemler sekmesine gidin.

  2. İş akışları listesinde ilgili iş akışını seçin.

    Örneğin, dosyanızda .yml aşağıdaki kod varsa, listede CI İş Akışı başlıklı bir bağlantı görüntülenir:

    name: CI Workflow
    
  3. Belirli bir koşuyu seçin.

    Durumu gösteren çalıştırmalar listesinde, incelemek istediğiniz çalıştırmanın zaman damgasını veya işleme iletisini seçin.

  4. Her bir işi ve adımı genişletin.

    Çalıştırma özeti sayfası, iş akışı dosyasında tanımlandığı şekilde işleri görüntüler, örneğin derleme veya test:

    1. Genişletmek için bir iş seçin.
    2. İşin içinde"Bağımlılıkları yükleme" veya "Testleri çalıştırma" gibi adımları tek tek genişletin.
  5. Günlük kaydı görüntüleyin.

    Konsol günlükleri, hata iletileri ve hata ayıklama bilgileri de dahil olmak üzere tam günlük çıkışını görüntülemek için bir iş akışı adımı seçin. Günlükleri kopyalayabilir, arayabilir ve indirebilirsiniz.

Aşağıdaki tabloda iş akışı günlüklerine erişmek için gerçekleştirdiğiniz adımlar özetlemektedir:

Eylem Amaç
Eylemler sekmesi Tüm iş akışı çalıştırmalarını görüntüleyin.
İş akışı adını seçin İş akışına göre filtre uygula.
Bir çalıştırma seçin Belirli iş ve adım sonuçlarına bakın.
Adımları genişlet Ayrıntılı günlükleri görüntüleyin.
Günlükleri indirme Çevrimdışı veya ekip sorunlarını gidermek için günlükleri indirin.

Yapı için eylem günlükleri

Bir iş akışı çalıştırıldığında, ne olduğunu ve hataların veya test hatalarının ayrıntılarını içeren bir günlük oluşturur.

Hata oluşursa veya test başarısız olursa günlüklerde yeşil onay işareti yerine kırmızı bir X görünür. Ne olduğunu araştırmak için hatanın veya başarısızlığın ayrıntılarını inceleyebilirsiniz.

Başarısız bir testle ilgili ayrıntıları içeren GitHub Actions günlüğünün ekran görüntüsü.

Yapıtlarla çalışma

Bir iş akışı günlük girdisi dışında bir şey ürettiğinde, bu yapı olarak adlandırılır. Örneğin, Node.js derlemesi dağıtılabilir bir Docker kapsayıcısı oluşturur. Kapsayıcı, actions/upload-artifact eylemini kullanarak depolamaya yükleyebileceğiniz bir yapıttır. Daha sonra actions/download-artifact kullanarak yapıtı depolama alanından indirebilirsiniz.

Bir yapıtın depolanması, bunu işler arasında korur. Her iş vm'nin yeni bir örneğini kullandığından yapıtı VM'ye kaydederek yeniden kullanamazsınız. Yapıtınızın farklı bir işte olması gerekiyorsa, yapıtı bir işteki depolama alanına yükleyebilir ve diğer iş için indirebilirsiniz.

Yapıt depolama

Yapıtlar GitHub'daki depolama alanında depolanır. Alan genel depolar için ücretsizdir ve hesaba bağlı olarak bazı depolama alanları özel depolar için ücretsizdir. GitHub yapıtlarınızı 90 gün boyunca depolar.

Aşağıdaki iş akışı parçacığında, actions/upload-artifact@main eyleminde bir path özniteliği olduğuna dikkat edin. Bu özniteliğin değeri, yapıtı depolama yoludur. Bu örnekte, her şeyi bir dizine yüklemek için public/ değerini belirtirsiniz. Yalnızca tek bir dosyayı karşıya yüklemek istiyorsanız public/mytext.txtgibi bir dosya kullanın.

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

Test için dosyayı indirmek için, derlemenin başarıyla tamamlanması ve dosyanın yüklenmesi gerekir. Aşağıdaki kodda, test işinin derleme işine bağlı olduğunu belirtirsiniz.

test:
    needs: build
    runs-on: ubuntu-latest

Aşağıdaki iş akışı parçacığında yapıtı indirirsiniz. Artık test işi test amaçlı artifaktı kullanabilir.

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

İş akışlarında yapıtları kullanma hakkında daha fazla bilgi için bkz . İş akışı verilerini yapıt olarak depolama.

İş akışlarını kullanarak GitHub'da incelemeleri otomatikleştirme

ve pushgibi pull-request GitHub olayları aracılığıyla iş akışı başlatmaya ek olarak, bir iş akışını zamanlamaya göre veya GitHub dışındaki bir olaydan sonra çalıştırabilirsiniz.

Bir iş akışının yalnızca bir kullanıcı belirli bir eylemi tamamladığında (örneğin, bir gözden geçiren bir pull isteğini onayladığında) çalışmasını isteyebilirsiniz. Bu senaryo için pull-request-review'yi tetikleyebilirsiniz.

Gerçekleştirebileceğiniz bir diğer eylem de çekme isteğine bir etiket eklemektir. Bu durumda pullreminders/label-when-approved-action işlemini kullanın.

Örneğin:

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

Bloğunda env , eylemin ortam değişkenlerini ayarlarsınız. Örneğin, iş akışını çalıştırmak için gereken onaylayanların sayısını ayarlayabilirsiniz. Bu örnekte bir tanesidir. eylemin bir etiket ekleyerek deponuzda değişiklik yapması gerektiğinden secrets.GITHUB_TOKEN kimlik doğrulama değişkeni gereklidir. Son olarak, eklenecek etiketin adını girersiniz.

Etiket eklemek, birleştirme gibi başka bir iş akışı başlatan bir olay olabilir. Bu olayı, GitHub Actions'da sürekli teslim kullanmayı açıklayan sonraki modülde ele alacağız.