GitHub Actions'ta Node 24 Geçişi Workflow'ları Nasıl Etkiler?

GitHub Actions’ta Node 24 geçişi, öncelikle workflow içinde kullanılan JavaScript tabanlı action’ların çalıştırıldığı dahili Node runtime katmanını etkiler. Bu değişiklik, Python testlerinizin, Java uygulamanızın veya .NET projenizin otomatik olarak Node 24 üzerinde çalışacağı anlamına gelmez.

Etkilenme düzeyini anlamak için workflow’u üç ayrı katmanda incelemek gerekir: action’ın kendi çalışma zamanı, projenin test veya build ortamı ve job’u çalıştıran runner sistemi.

Node runtime geçişi workflow'un hangi katmanını etkiler?

Bir workflow içindeki uses: adımı, başka bir depoda veya aynı depoda tanımlanmış action’ı çağırabilir. Bu action JavaScript ile hazırlanmışsa action’ın paketlenmiş kodunu çalıştırmak için runner’ın yönettiği Node runtime kullanılır. actions/checkout gibi yaygın action’lar ile üçüncü taraf JavaScript action’ları bu katmanda değerlendirilir.

GitHub Node 20 kullanım dışı bırakma duyurusu, runner’ların 16 Haziran 2026’dan itibaren JavaScript action’larını varsayılan olarak Node 24 ile çalıştırmaya başladığını belirtiyor. Duyuruya göre Node 20’nin runner’dan kaldırılması 23 Eylül 2026 için planlanıyor. Dolayısıyla geçici geri dönüş seçeneğine güvenmek yerine kullanılan action sürümlerini uyumluluk açısından kontrol etmek gerekir.

Bu değişiklik ile proje runtime’ını birbirine karıştırmamak önemlidir. Örneğin workflow’unuz önce Python kuruyor, ardından pytest çalıştırıyorsa test kodunuz seçtiğiniz Python yorumlayıcısında yürütülür. Benzer biçimde Maven veya Gradle komutları JVM üzerinde, dotnet test komutu ise kurulan .NET SDK üzerinde çalışır. Node 24 burada test edilen uygulamanın dili değil, JavaScript action’ının yürütme motorudur.

Git ve CI/CD iş akışlarını ilk kez kuruyorsanız video yazılım eğitimleri ile yalnızca YAML satırlarını değil, kaynak kod yönetimi ile otomatik test arasındaki ilişkiyi birlikte ele almak daha kalıcı bir temel oluşturabilir.

Hangi action türleri doğrudan veya dolaylı etkilenebilir?

• JavaScript action’ları: Node runtime değişikliğinin doğrudan hedefidir. Eski bağımlılıklar veya artık desteklenmeyen Node API’leri nedeniyle uyumluluk sorunu yaşayabilir.
• Composite action’lar: Temelde shell adımlarını birleştirebilir; ancak içinde JavaScript tabanlı başka bir action çağırıyorsa dolaylı olarak etkilenebilir.
• Docker container action’ları: Kendi container giriş noktalarıyla çalıştıkları için runner’ın JavaScript action runtime’ından doğrudan etkilenmez. Buna rağmen workflow içindeki diğer uses: adımları etkilenebilir.
• run: komutları: Python, Java, .NET veya shell komutları seçilen proje ortamında çalışır. Bu adımların kullandığı Node sürümü ayrıca kurulmadıkça action runtime değişikliğiyle aynı şey değildir.
• Self-hosted runner’lar: Runner yazılımının yeni runtime’ı desteklemesi ve işletim sistemi ile işlemci mimarisinin uyumlu olması gerekir.

Hızlı karar çerçevesi

1. Workflow’ta uses: ile çağrılan action’ları listeleyin.
2. Her action’ın güncel ana sürümünü ve JavaScript tabanlı olup olmadığını kontrol edin.
3. run: adımlarında kullanılan Python, JDK veya .NET SDK sürümlerini ayrı bir liste olarak değerlendirin.
4. Hata bir action başlamadan önce oluşuyorsa action runtime’ını; test komutu başladıktan sonra oluşuyorsa proje runtime’ını araştırın.

runs-on etiketi gerçek runner ortamını nasıl belirler?

runs-on, bir job’un hangi runner sınıfında çalışacağını belirler. ubuntu-latest, windows-latest ve macos-latest gibi etiketler GitHub tarafından yönetilen runner imajlarını seçer. Seçilen imaj; işletim sistemini, işlemci mimarisini, önceden kurulu araçları ve kullanılabilir sistem bileşenlerini etkiler.

latest ifadesi sabitlenmiş bir işletim sistemi sürümü anlamına gelmez. GitHub Actions Runner Images belgeleri, bu etiketlerin en yeni kararlı imajlara yönlendirildiğini ve geçişlerin kademeli yapılabildiğini açıklıyor. Ayrıca runner imajlarındaki araçlar düzenli olarak güncellendiğinden aynı workflow dosyası değiştirilmeden farklı bir imaj revizyonunda çalışabilir.

Node 24 action runtime’ı ile runner imajında komut satırından erişilebilen node programı da aynı kavram değildir. Action runtime’ını runner uygulaması yönetirken terminaldeki node --version çıktısı, imaja önceden kurulmuş veya workflow tarafından ayrıca kurulmuş proje aracını gösterebilir.

Bu katmanları uygulamalı olarak ayırmayı öğrenmek, canlı yazılım eğitimleri sırasında ele alınan “komutu ezberlemek yerine çalışma ortamını teşhis etme” yaklaşımıyla da örtüşür. Amaç yalnızca başarılı bir YAML dosyası elde etmek değil, başarısızlığın hangi katmanda oluştuğunu okuyabilmektir.

Geçiş öncesi kontrol listesi: action, runner ve Node ayarları

Node 24 geçişinden önce amaç, projenizin Python, JVM veya .NET sürümünü değiştirmek değil; workflow içinde çalışan JavaScript tabanlı action'ların ve runner ortamının uyumunu kontrol etmektir. İlk incelemeyi, özellikle Python test akışlarında, mevcut uygulamalı otomasyon öğrenme çalışmaları gibi adım adım ilerleyen bir yöntemle yapmak gereksiz değişiklikleri azaltır.

1. Action sürümlerini listeleyin. Workflow dosyalarındaki tüm uses: satırlarını çıkarın ve eski major sürümleri işaretleyin. Örneğin actions/checkout@v2 gibi uzun süredir değiştirilmemiş bir action, yeni runner veya Node ortamında doğrudan bozulmak zorunda değildir; ancak uyumluluk, güvenlik ve destek kapsamı ayrıca incelenmelidir. GitHub'ın güncel Python workflow dokümanlarında actions/checkout@v6 ve actions/setup-python@v6 örneklenmektedir. Bu major sürümlerin ve eski sürümlerden geçiş yolunun yayın öncesinde GitHub Actions Python dokümantasyonu ile doğrulanması gerekir.
2. runs-on etiketini kontrol edin. ubuntu-latest, belirli bir işletim sistemi imajına kalıcı olarak eşit değildir; GitHub bu etiketi zaman içinde daha yeni bir imaja taşıyabilir. Daha kontrollü bir inceleme için workflow'da kullanılan etiketi ve “Set up job” loglarındaki “Runner Image” bölümünü karşılaştırın. Açık bir imaj etiketi kullanmak, işletim sistemi kaynaklı değişkenliği azaltabilir; ancak imajın kurulu araçları ve sürümleri yine de ayrıca kontrol edilmelidir.
3. Self-hosted runner ayrıntılarını doğrulayın. Kendi runner'ınızı kullanıyorsanız işletim sistemi, CPU mimarisi, runner uygulamasının sürümü ve ağ erişimi birlikte incelenmelidir. Node 24 kullanan action'lar için runner sürüm gereksinimi action'ın kendi dokümantasyonunda belirtilir. Örneğin setup-python v6, Node 24'e geçirilmiş ve en az belirli bir Actions Runner sürümü gerektirdiğini belirtmektedir. ARM32 gibi mimarilerde ayrıca işletim sistemi ve Node uyumluluğunu doğrulamadan geçiş kararı vermeyin.
4. Runtime katmanlarını birbirinden ayırın. actions/setup-python içindeki python-version: '3.12', projenin Python yorumlayıcısını belirler; action'ın Node 24 ile çalışması bu ayarı Node 24'e dönüştürmez. Aynı ayrım Java için JVM, .NET için .NET SDK ve action'ın JavaScript runtime'ı arasında geçerlidir. Hatanın hangi katmana ait olduğunu anlamadan proje runtime'ını yükseltmeyin.
5. İki log bölgesini inceleyin. Önce “Set up job” adımında runner image, işletim sistemi, mimari ve runner sürümünü okuyun. Ardından başarısız action adımının loguna bakın. checkout veya setup-python başlamadan oluşan “runtime”, “runner” ya da action yükleme hatası ile pytest sırasında görülen assertion/test hatası aynı problem değildir. İlk grup workflow altyapısını, ikinci grup uygulama kodunu işaret eder.

Ayrı branch ve matrix ile geçiş güvenli biçimde nasıl denenir?

“Çalışıyorsa dokunma” yaklaşımı, geçiş riskini ortadan kaldırmaz; yalnızca ilk hatayı ana branch üzerinde görünür hâle getirir. Bunun yerine değişikliği ayrı bir branch'e alın, workflow_dispatch ile manuel tetikleyin ve iki runner imajını aynı test komutuyla karşılaştırın. GitHub'ın workflow sözdiziminde manuel tetikleme ve matrix stratejisi desteklenir; kullanılan etiketlerin güncel durumunu yayın öncesi resmî workflow sözdizimi dokümanından kontrol edin.

name: Python geçiş denemesi

on:
  workflow_dispatch:

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-24.04, ubuntu-26.04]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v6
        with:
          python-version: '3.12'
      - run: python -m pip install -r requirements.txt
      - run: pytest -q

Bu örnekte ubuntu-24.04 ile ubuntu-26.04 aynı şey değildir; ikinci seçenek farklı araç sürümleri veya önizleme durumuyla ek değişken oluşturabilir. Dolayısıyla sonuçları iki aşamada okuyun: Önce amaç yalnızca Node 24 tabanlı action uyumluluğunu sınamaksa aynı runner imajında action değişikliğini deneyin. İşletim sistemi imajının etkisini de ölçmek istiyorsanız matrix sonuçlarını ayrı karşılaştırın.

• Başarılı akışta her iki job için checkout ve Python kurulumu tamamlanır; son satırlarda 2 passed benzeri pytest özeti görülür.
• Checkout veya setup adımı başarısızsa test komutuna hiç ulaşılmamıştır. Öncelik action major sürümü, runner sürümü, imaj etiketi ve ağ erişimidir.
• pytest -q çalışıp assertion veya test collection hatası veriyorsa Node geçişinden çok proje bağımlılıkları, test keşfi ya da Python ortamı incelenmelidir.

Bu küçük deneme alanı, action runtime'ı ile Python runtime'ını ayrı ayrı gözlemlemenizi sağlar. Sonuçlar tutarlıysa değişikliği ana branch'e taşıyın; farklıysa önce hangi matrix hücresinde, hangi adımda ve hangi log satırında ayrışma başladığını kaydedin.

Workflow neden aniden bozuldu? Loglardan adım adım teşhis

Node runtime geçişinden sonra bir workflow bozulduğunda ilk varsayımınız Python, Java veya .NET projesinin çalışma sürümünün değiştiği olmamalıdır. GitHub Actions içindeki JavaScript tabanlı bir action'ın çalıştırıldığı Node runtime ile projenizin kullandığı Python yorumlayıcısı, JDK veya .NET SDK birbirinden ayrı katmanlardır. Teşhis için önce hatanın action başlatılırken mi, runner hazırlanırken mi, yoksa test/build komutu çalışırken mi oluştuğunu ayırın.

GitHub Actions arayüzünde başarısız bir çalıştırmayı açıp ilgili job’a girin. GitHub Docs’a göre job içinde GitHub’ın eklediği Set up job ve Complete job adımlarının yanı sıra workflow dosyanızdaki adımlar listelenir; GitHub-hosted runner kullanılan işlerde Set up job bölümü runner image bilgilerini ve önceden kurulu araçların listesini gösterir. GitHub Docs workflow run logları üzerinden belirli bir log satırına kalıcı bağlantı da oluşturabilirsiniz.

1. Workflow dosyasını açın ve action sürümlerini listeleyin

Önce hatanın oluştuğu commit’teki .github/workflows/*.yml veya .yaml dosyasını inceleyin. Yalnızca açıkça “Node 24” yazan satırlara bakmayın; JavaScript tabanlı action’lar kendi metadata dosyalarında hangi Node runtime’ını kullanacaklarını belirtir. Örneğin actions/checkout, actions/setup-python veya cache kullanan bir action’ın sürümü, proje kodunuzdan bağımsız olarak action katmanını etkileyebilir.

• uses: ile başlayan tüm action’ları çıkarın.
• Major sürüm, commit SHA veya tag kullanılıp kullanılmadığını not edin.
• Son başarılı çalıştırmayla ilk başarısız çalıştırmadaki action listesini karşılaştırın.
• Yerel veya kurum içi JavaScript action kullanılıyorsa action’ın action.yml dosyasındaki runs.using değerini kontrol edin.

Bu aşamada amaç hemen bütün action’ları güncellemek değil, hangi action’ın değişiklikten etkilenmiş olabileceğini daraltmaktır. Bir action’ın Node runtime’ı ile proje içindeki python, java, dotnet veya pytest komutlarının çalışma ortamını aynı şeymiş gibi değerlendirmeyin.

2. runs-on etiketinin gerçekte ne seçtiğini kontrol edin

İkinci kontrol noktası job tanımındaki runs-on satırıdır. ubuntu-latest, ubuntu-24.04, windows-latest veya macos-latest gibi bir etiket GitHub-hosted runner image seçer. -latest etiketleri sabit bir işletim sistemi sürümü anlamına gelmez; GitHub’ın sağladığı güncel kararlı image’a işaret eder. Bu nedenle image değişikliği, önceden kurulu paketleri, sistem kütüphanelerini, shell davranışını veya araç sürümlerini etkileyebilir.

Loglarda önce Set up job adımını genişletin ve Runner Image, işletim sistemi, mimari ve image sürüm notlarını inceleyin. Beklenen alan adları arayüz zaman içinde değişebileceği için aşağıdaki metin gerçek bir GitHub logundan alınmış alıntı değil, yalnızca teşhis mantığını göstermek için hazırlanmış örnekleştirilmiş çıktıdır:

Set up job
  Runner image: GitHub-Hosted Runner
  Operating system: Linux
  Architecture: X64
  Runner image details: available in the job summary

Run actions/checkout@...
  Preparing action execution

Run pytest
  collected 8 items
  8 passed

Burada belirli bir Node veya image sürüm numarası verilmemesinin nedeni, bu değerlerin runner türüne ve çalıştırma zamanına göre değişebilmesidir. Asıl sorulması gereken soru şudur: Başarısız job, önceki başarılı job’a göre farklı bir image veya farklı bir runner üzerinde mi çalıştı?

3. Self-hosted runner kullanılıyorsa makineyi ayrıca doğrulayın

runs-on: [self-hosted, linux, x64] gibi bir tanım görüyorsanız GitHub’ın temiz bir sanal makinesini değil, sizin yönettiğiniz bir runner’ı inceliyorsunuz demektir. Self-hosted runner’da işletim sistemi, işlemci mimarisi, runner uygulaması, ağ erişimi, kurulu Node bileşenleri ve sistem kütüphaneleri sizin sorumluluğunuzdadır. GitHub Docs, self-hosted runner etiketlerinin işletim sistemi ve mimariyi ifade edebildiğini; ancak özel etiketlerin makinenin gerçeğini otomatik olarak doğrulamadığını belirtir. GitHub Docs self-hosted runner referansı ile makinenin desteklenen işletim sistemi, mimari ve runner bakım koşullarını karşılaştırın.

Runner makinesinde aşağıdaki bilgileri kayıt altına alın:

• İşletim sistemi ve sürümü,
• CPU mimarisi: x64, ARM64 veya başka bir hedef,
• GitHub Actions runner uygulamasının durumu ve sürümü,
• Action’ın ihtiyaç duyduğu Node bileşenlerinin erişilebilirliği,
• Python, JDK veya .NET SDK’nın ayrıca kurulu olup olmadığı,
• PATH, proxy, sertifika, Docker ve dosya izinleri.

Etiket “linux” veya “x64” olsa bile makineyi yalnızca bu etikete bakarak doğru kabul etmeyin. Etiket yanlış atanmış olabilir veya runner zaman içinde elle değiştirildiği için workflow’un beklediği ortamdan uzaklaşmış olabilir.

4. Başarısız adımı loglardan izole edin

Teşhisin en önemli bölümü, ilk kırılma noktasını bulmaktır. Job’ın en sonunda görünen hata her zaman asıl neden değildir. Örneğin actions/setup-python başlatılamadıysa daha sonra çalışan pytest adımının hiç başlamamış olması mümkündür. Buna karşılık setup adımları başarıyla tamamlanmış ve hata doğrudan test komutunda oluşmuşsa Node runtime geçişi yalnızca zamanlama bakımından yakın bir değişiklik olabilir.

1. Set up job bölümünde runner image, işletim sistemi ve mimariyi kontrol edin.
2. İlk uses: adımını açın ve action’ın başlatılıp başlatılmadığına bakın.
3. Node.js runtime, cannot find module, unsupported platform veya uyumluluk ifadelerini action loglarında arayın.
4. Setup adımları başarılıysa proje runtime’ını kontrol edin: python --version, java -version veya dotnet --info.
5. Son olarak doğrudan test/build çıktısını inceleyin: bağımlılık kurulumu, import, derleme, assertion veya test sonucu hatası mı var?

Kalıcı çözüm: workflow'u değişikliklere karşı gözlemlenebilir tutmak

Geçiş tamamlandıktan sonra hedef yalnızca workflow’un yeniden yeşile dönmesi olmamalıdır. Bir sonraki action runtime, runner image veya işletim sistemi değişikliğinde hangi katmanın etkilendiğini hızlıca anlayabilmek için workflow gözlemlenebilir tasarlanmalıdır. Bunun temel yolu, action ile proje komutlarını aynı belirsiz adım içinde birleştirmemektir.

Action sürümlerini ve runner seçimini düzenli gözden geçirin

Workflow dosyasında kullanılan action’ları dönemsel olarak listeleyin. Major sürüm değişikliklerini doğrudan ana branch üzerinde denemek yerine önce küçük bir değişiklik kümesiyle doğrulayın. Action sürümünü yükseltirken aynı commit’te gereksiz biçimde Python, Java veya .NET bağımlılıklarını da değiştirmemek, sorun çıktığında neden-sonuç ilişkisini korur.

runs-on seçimi de bilinçli yapılmalıdır. -latest etiketleri bakım yükünü azaltır; ancak image değişikliklerini tamamen görünmez kılmaz. Belirli bir işletim sistemi davranışına, sistem kütüphanesine veya derleyici aracına bağımlı projelerde sabit bir image etiketi daha kontrollü bir başlangıç noktası sağlayabilir. Bu tercih, “bir etiket her durumda daha iyidir” şeklinde değil, projenin uyumluluk ve bakım ihtiyacına göre yapılmalıdır.

Self-hosted runner envanterini belgeleyin

Self-hosted runner kullanılıyorsa her makine için en azından işletim sistemi, mimari, runner uygulaması, kurulu proje runtime’ları, Docker durumu ve özel etiketleri belgeleyin. Aynı etiketi taşıyan iki makinenin farklı paketlere sahip olması, geçiş sonrası aralıklı ve zor tekrarlanan hatalara yol açabilir.

• Runner adı ve bağlı olduğu repository veya grup
• İşletim sistemi ve mimari
• Python, JDK, .NET SDK ve diğer kritik araçların sürüm politikası
• Runner güncelleme yöntemi
• Özel label’ların hangi teknik koşulu ifade ettiği
• Son doğrulama tarihi ve sorumlu kişi

GitHub’ın self-hosted runner belgelerinde otomatik güncellemelerin yönetilebildiği, ancak güncellemeleri devre dışı bırakan ekiplerin runner yazılımını düzenli biçimde kendilerinin güncellemesi gerektiği açıklanır. Bu nedenle “runner bir kez kuruldu, artık sabittir” yaklaşımı güvenilir değildir.

Manuel doğrulama workflow'u bulundurun

Üretim dağıtımından bağımsız, yalnızca ortamı kontrol eden bir workflow yararlı olur. Bu workflow aşağıdaki bilgileri açıkça yazdırabilir:

name: Environment check

on:
  workflow_dispatch:

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Runner bilgisi
        run: |
          uname -a
          python --version
      - name: Pytest sürümü
        run: |
          python -m pip --version
          pytest --version

Bu tür bir kontrol, Node runtime ile pytest’in aynı runtime olmadığını log üzerinde görünür kılar. Benzer yaklaşım Java için java -version, .NET için dotnet --info komutlarıyla uygulanabilir. Hata loglarında action adımlarını proje test/build adımlarından ayrı tuttuğunuzda, gelecekteki runtime değişiklikleri için aynı teşhis yöntemi tekrar kullanılabilir.

Geçiş sonrası kontrol listesi

• Başarılı bir çalıştırmada runner image ve işletim sistemi kaydedildi mi?
• Tüm uses: adımları ve sürümleri gözden geçirildi mi?
• Action runtime ile proje runtime’ı ayrı ayrı doğrulandı mı?
• Self-hosted runner kullanılıyorsa işletim sistemi, mimari ve etiketler belgelendi mi?
• Manuel çalıştırılabilen bir ortam kontrol workflow’u mevcut mu?
• Test/build hataları ile action başlatma hataları farklı adımlarda görülebiliyor mu?
• Bir sonraki image veya runtime değişikliğinde karşılaştırma yapılabilecek son başarılı log saklandı mı?

Bu kontrol listesi belirli bir Node sürümüne bağlı değildir. Aynı yöntem, ileride JavaScript action runtime’ı, GitHub runner image’ı veya self-hosted runner bileşenleri değiştiğinde de uygulanabilir: önce ortamı tanımlayın, sonra action katmanını, en son proje test/build katmanını inceleyin.

Sık Sorulan Sorular

Node runtime değişikliği Python, Java veya .NET uygulamamın çalışma sürümünü otomatik olarak değiştirir mi?

Hayır. JavaScript tabanlı GitHub Actions action’larının Node runtime’ı ile uygulamanızın Python yorumlayıcısı, JDK’sı veya .NET SDK’sı ayrı katmanlardır. Uygulama runtime’ı ancak workflow içinde ilgili setup adımı, runner image değişikliği veya self-hosted makine yapılandırması nedeniyle farklılaşabilir.

actions/checkout veya actions/setup-python sürümünü güncellemeden workflow'u çalıştırmak güvenli midir?

Bir workflow’un güncelleme yapılmadan çalışması mümkün olabilir; ancak güvenli olup olmadığı action’ın kullandığı runtime, runner sürümü ve mevcut uyumluluk koşulları incelenmeden söylenemez. Önce son başarılı çalıştırmayla mevcut logları karşılaştırın, ardından güncellemeyi ayrı bir branch veya kontrollü çalıştırmayla doğrulayın.

ubuntu-latest ile sabit bir runner image etiketi arasındaki fark nedir?

ubuntu-latest, GitHub’ın güncel kararlı image yönlendirmesini takip eder ve zaman içinde başka bir Ubuntu image’ına taşınabilir. Sabit bir etiket ise workflow’un hedeflediği işletim sistemi image’ını daha açık ifade eder. Sabit etiket daha öngörülebilir olabilir; fakat image’ın yaşam döngüsü ve destek durumu yine takip edilmelidir.

Self-hosted runner kullanıyorsam Node ve runner ortamını nasıl kontrol etmeliyim?

Makinenin işletim sistemini, CPU mimarisini, GitHub Actions runner uygulamasını, ağ erişimini, PATH değerini ve action’ın ihtiyaç duyduğu Node bileşenlerini kontrol edin. Ayrıca Python, JDK veya .NET SDK’yı ayrı olarak doğrulayın. Runner etiketlerini yalnızca isim olarak değil, makinenin gerçek özellikleriyle karşılaştırın.

Workflow geçişten sonra bozulduğunda önce hangi log adımına bakmalıyım?

Önce Set up job bölümünü açarak runner image, işletim sistemi ve mimariyi kontrol edin. Ardından ilk JavaScript action’ın loglarına bakın. Bu adımlar başarılıysa proje runtime’ını kuran setup adımına ve son olarak pytest, Maven, Gradle, MSBuild veya benzeri test/build komutunun ilk hata satırına geçin.

Sağlam bir teşhis süreci, Node runtime geçişini tek başına suçlamak yerine runner, action ve proje katmanlarını kanıtlarına göre birbirinden ayırır.