İşlem hattı çalıştırmalarıyla ilgili sorunları giderme

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

İşlem hattı çalıştırmanız tamamlanamadıysa, sorunun giderilmesine yardımcı olması için işlem hattı çalıştırması özet sayfası tarafından sağlanan tanılama bilgilerini ve günlükleri kullanabilirsiniz.

Günlükleri görüntüleme

Tamamlanamadıktan sonra görevin günlüklerini görüntülemek için hata iletisini seçin.

Günlükler sayfası görüntülenir ve hata seçili durumdadır. Bu örnekte, görevde echo komutu olarak echgirildiği bir hata cmd-line vardır.

Ham günlüğü görüntüle'yi seçerek görevin ham günlüğünü görüntüleyebilir ve Bul'u kullanarak günlükte arama yapabilirsiniz.

Hata bilgileri ve görevin neden başarısız olduğuna ilişkin ipuçları için başarısız olan görevin günlüklerini tarayın. Varsayılan olarak, boş olmayan günlükler bir işlem hattı çalıştırması tarafından oluşturulur. Varsayılan günlükler sorunun nedenini göstermiyorsa ayrıntılı günlükleri yapılandırarak daha fazla bilgi edinebilirsiniz.

İşlem hattı çalıştırma özet sayfasından veya günlüklere göz atmadan sorun görünmüyorsa, aşağıdaki Yaygın sorunlar bölümünü gözden geçirin ve ek tanılama bilgileri içeren tam günlükleri indirme hakkında bilgi için işlem hattı sorunlarını tanılamak için günlükleri gözden geçirme bölümüne bakın.

Genel sorunlar

• İş zaman aşımı
• Kod indirme sorunları
• İşlem hattım MSBUILD gibi bir komut satırı adımında başarısız oluyor
• Dosya veya klasör kullanımda hataları
• Aralıklı veya tutarsız MSBuild hataları
• İşlem yanıt vermeyi durduruyor
• Birden çok platform için satır sonları
• ' (tek tırnak) eklenmiş değişkenler
• Hizmet Bağlantısı ile ilgili sorunlar
• İşlem hattı aracıdan duymayı durdurdu

İş zaman aşımı

İşlem hattı uzun süre çalışabilir ve sonra iş zaman aşımı nedeniyle başarısız olabilir. İş zaman aşımı, kullanılan aracıya bağlıdır. Microsoft tarafından barındırılan ücretsiz aracılar, özel bir depo için iş başına en fazla 60 dakika ve genel depo için en fazla 360 dakika zaman aşımına sahiptir. Bir işin en fazla zaman aşımı süresini artırmak için aşağıdakilerden birini tercih edebilirsiniz.

• Kullanılan depodan bağımsız olarak tüm işler için size 360 dakika süre tanıyacak Microsoft tarafından barındırılan bir aracı satın alın
• Aracıdan kaynaklanan zaman aşımı sorunlarını elemek için şirket içinde barındırılan aracı kullanma

İş zaman aşımı hakkında daha fazla bilgi edinin.

Kod indirme sorunları

• İşlem hattım bir kullanıma alma adımında başarısız oluyor
• Team Foundation Sürüm Denetimi (TFVC) sorunları

İşlem hattım bir kullanıma alma adımında başarısız oluyor

Kuruluşunuzda işlem hattınızdan farklı bir checkout projede yer alan bir Azure Repos Git deposunda bir adım kullanıyorsanız, İş yetkilendirme kapsamını geçerli projeyle sınırla ayarının devre dışı bırakıldığından emin olun veya işlem hattınızın depoya erişimi olduğundan emin olmak için Kapsamlı derleme kimlikleri'ndeki adımları izleyin.

İşlem hattınız sınırlı iş yetkilendirme kapsamı nedeniyle depoya erişemiyorsa hatayı Git fetch failed with exit code 128 alırsınız ve günlükleriniz şuna benzer bir giriş içerir: Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

İşlem hattınız ile Could not find a project that corresponds with the repositoryhemen başarısız oluyorsa, adım veya depo kaynak bildiriminde checkout projenizin ve deponuzun adının doğru olduğundan emin olun.

Team Foundation Sürüm Denetimi (TFVC) sorunları

• Bazı dosyaların indirilmediği kaynakları alma
• Team Foundation Proxy aracılığıyla kaynakları alma

Bazı dosyaların indirilmediği kaynakları alma

Bu, komutundan "Tüm dosyalar güncel" günlüğündeki bir iletiyle tf get karakterize edilebilir. Yerleşik hizmet kimliğinin kaynakları indirme izni olduğunu doğrulayın. Derleme işlem hattının Genel sekmesinde seçilen yetkilendirme kapsamına bağlı olarak, Kimlik Proje Koleksiyonu Derleme Hizmeti veya Proje Derleme Hizmeti'nin kaynakları indirme izni gerekir. Sürüm kontrolü web kullanıcı arayüzünde, klasör hiyerarşisinin herhangi bir seviyesindeki proje dosyalarına göz atabilir ve güvenlik ayarlarını kontrol edebilirsiniz.

Team Foundation Proxy aracılığıyla kaynakları alma

Team Foundation Proxy aracılığıyla kaynakları almak için aracıyı yapılandırmanın en kolay yolu, aracının kullanıcı olarak çalıştırılması için TFVC proxy sunucusuna işaret eden ortam değişkeni TFSPROXY ayarlamaktır.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

İşlem hattım MSBUILD gibi bir komut satırı adımında başarısız oluyor

Derleme veya yayın hatasının Azure Pipelines/TFS ürün sorununun (aracı veya görevler) sonucu olup olmadığını daraltmak yararlı olur. Derleme ve yayın hataları da dış komutlardan kaynaklanabilir.

Başarısız görev tarafından yürütülen tam komut satırı için günlükleri denetleyin. Komutu komut satırından yerel olarak çalıştırmaya çalışmak sorunu yeniden üretebilir. Komutunu kendi makinenizden yerel olarak çalıştırmak ve/veya makinede oturum açıp komutu hizmet hesabı olarak çalıştırmak yararlı olabilir.

Örneğin, sorun derleme işlem hattınızın MSBuild bölümü sırasında mı oluyor (örneğin, MSBuild veya Visual Studio Derleme görevini mi kullanıyorsunuz)? Öyleyse, aynı bağımsız değişkenleri kullanarak yerel bir makinede aynı MSBuild komutunu çalıştırmayı deneyin. Sorunu yerel bir makinede yeniden oluşturabiliyorsanız, sonraki adımlarınız MSBuild sorununu araştırmaktır.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Yerel komut istemi ve aracı arasındaki farklar

Yerel makinede bir komut yürütülürken ve bir aracıda derleme veya yayın çalıştırılırken bazı farklılıkların geçerli olduğunu unutmayın. Aracı Linux, macOS veya Windows'da hizmet olarak çalışacak şekilde yapılandırılmışsa, etkileşimli bir oturum açma oturumu içinde çalışmıyor demektir. Etkileşimli oturum açma oturumu olmadan kullanıcı arabirimi etkileşimi ve diğer sınırlamalar vardır.

Dosya veya klasör kullanımda hataları

File or folder in use hatalar genellikle aşağıdaki gibi hata iletileriyle gösterilir:

• Access to the path [...] is denied.
• The process cannot access the file [...] because it is being used by another process.
• Access is denied.
• Can't move [...] to [...]

Sorun giderme adımları:

• Kullanımdaki dosyaları ve klasörleri algılama
• Virüsten koruma dışlaması
• MSBuild ve /nodeReuse:false
• MSBuild ve /maxcpucount:[n]

Kullanımdaki dosyaları ve klasörleri algılama

Windows'da İşlem İzleyicisi gibi araçlar belirli bir dizin altında dosya olaylarının izini yakalamak olabilir. Öte yandan anlık görüntü için İşlem Gezgini veya Tanıtıcı gibi araçlar da kullanılabilir.

Virüsten koruma dışlaması

Dosyalarınızı tarayan virüsten koruma yazılımı, derleme veya yayın sırasında dosya veya klasörün kullanımda hatalara neden olabilir. Aracı dizininiz için bir virüsten koruma dışlaması eklemek ve yapılandırılan "çalışma klasörü", virüsten koruma yazılımını engelleme işlemi olarak belirlemeye yardımcı olabilir.

MSBuild ve /nodeReuse:false

Derlemeniz sırasında MSBuild'i çağırırsanız bağımsız değişkenini /nodeReuse:false (kısa form /nr:false) geçtiğinizden emin olun. Aksi takdirde DERLEME tamamlandıktan sonra MSBuild işlemleri çalışmaya devam eder. İşlemler bir süre daha olası bir sonraki derlemeyi beklemeye devam eder.

MSBuild'in bu özelliği, MSBuild işleminin (es) çalışma diziniyle çakışma nedeniyle bir dizini silme veya taşıma girişimlerini engelleyebilir.

MSBuild ve Visual Studio Derleme görevleri, MSBuild'e geçirilen bağımsız değişkenlere zaten eklenir /nr:false . Ancak, MSBuild'i kendi betiğinizden çağırırsanız bağımsız değişkenini belirtmeniz gerekir.

MSBuild ve /maxcpucount:[n]

Varsayılan olarak MSBuild ve Visual Studio Derlemesi gibi derleme görevleri MSBuild'i /m anahtarla çalıştırır. Bazı durumlarda bu, birden çok işlem dosyası erişim sorunu gibi sorunlara neden olabilir.

MSBuild'i /m:1 aynı anda yalnızca bir işlemi çalıştırmaya zorlamak için derleme görevlerinize bağımsız değişkenini eklemeyi deneyin.

MSBuild'in eşzamanlı işlem özelliğinden yararlanılırken dosya kullanımı sorunları oluşabilir. Bağımsız değişkenin /maxcpucount:[n] belirtilmemesi (kısa form /m:[n]), MSBuild'e yalnızca tek bir işlem kullanmasını ister. MSBuild veya Visual Studio Derleme görevlerini kullanıyorsanız, varsayılan olarak eklenen "/m" bağımsız değişkenini geçersiz kılmak için "/m:1" belirtmeniz gerekebilir.

Aralıklı veya tutarsız MSBuild hataları

Aralıklı veya tutarsız MSBuild hatalarıyla karşılaşıyorsanız, MSBuild'e yalnızca tek işlem kullanma talimatını verin. Aralıklı veya tutarsız hatalar, hedef yapılandırmanızın MSBuild'in eşzamanlı işlem özelliğiyle uyumsuz olduğunu gösterebilir. Bkz. MSBuild ve /maxcpucount:[n].

İşlem yanıt vermeyi durduruyor

İşlem, nedenlere yanıt vermeyi ve sorun giderme adımlarını durdurur:

• Giriş Bekleniyor
• İşlem dökümü
• WiX projesi

Giriş Bekleniyor

Yanıt vermeyi durduran bir işlem, bir işlemin giriş beklediğini gösterebilir.

Aracıyı etkileşimli oturum açmış oturumun komut satırından çalıştırmak, bir işlemin giriş için bir iletişim kutusu isteyip istemediğinizi belirlemenize yardımcı olabilir.

Aracıyı hizmet olarak çalıştırmak, programların giriş istemesini ortadan kaldırmaya yardımcı olabilir. Örneğin. .NET'te programlar, sorup sormayacağını belirlemek için System.Environment.UserInteractive Boolean'a güvenebilir. Aracı bir Windows hizmeti olarak çalışırken değer false değeridir.

İşlem dökümü

İşlemin dökümünü analiz etmek, kilitlenmeye neden olan bir işlemin ne beklediğini belirlemeye yardımcı olabilir.

WiX projesi

Özel MSBuild günlükçüleri etkinleştirildiğinde WiX projesi oluşturmak, WiX'in çıkış akışında beklerken kilitlenmesine neden olabilir. Ek MSBuild bağımsız değişkeninin /p:RunWixToolsOutOfProc=true eklenmesi soruna geçici bir çözüm olacaktır.

Birden çok platform için satır sonları

İşlem hatlarını birden çok platformda çalıştırdığınızda, bazen farklı satır sonlarıyla ilgili sorunlarla karşılaşabilirsiniz. Geçmişte Linux ve macOS satır besleme (LF) karakterleri kullanırken Windows satır başı ve satır besleme (CRLF) kullanıyordu. Git, satırların otomatik olarak depoda LF ile bitmesini ancak Windows'daki çalışma dizininde CRLF'nin olmasını sağlayarak farkı telafi etmeye çalışır.

Çoğu Windows aracı yalnızca LF sonlarında sorun yoktur ve bu otomatik davranış, çözdüğünden daha fazla soruna neden olabilir. Satır sonlarını temel alan sorunlarla karşılaşırsanız Git'i her yerde LF'yi tercih etmek üzere yapılandırmanızı öneririz. Bunu yapmak için deponuzun köküne bir .gitattributes dosya ekleyin. Bu dosyaya aşağıdaki satırı ekleyin:

* text eol=lf

' (tek tırnak) eklenmiş değişkenler

İşlem hattınızda komutunu kullanarak ##vso değişkenleri ayarlayan bir Bash betiği varsa, ayarladığınız değişkenin değerine ek ' bir ek eklendiğini görebilirsiniz. Bu, set -x ile olan bir etkileşim nedeniyle oluşur. Çözüm, değişken ayarlamadan önce set -x'i geçici olarak devre dışı bırakmaktır. Bunu yapmak için Bash sözdizimi set +x şeklindedir.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Bu neden gerçekleşir?

Birçok Bash betikleri hata ayıklamaya set -x yardımcı olmak için komutunu içerir. Bash tam olarak hangi komutun yürütüleceğini izler ve stdout'a yankılar. Bu, aracının komutu iki kez görmesine ##vso neden olur ve bash ikinci kez karakteri sonuna eklemiş ' olur.

Örneğin, şu işlem hattını göz önünde bulundurun:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

stdout'ta aracı iki satır görür:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Aracı ilk satırı gördüğünde doğru MY_VAR değer olan "my_value" olarak ayarlanır. Ancak, ikinci satırı gördüğünde aracı her şeyi satırın sonuna kadar işler. MY_VAR "my_value" olarak ayarlanır.

Betik yürütülürken Python uygulaması için kitaplıklar yüklenmez

Python uygulaması dağıtıldığında, bazı durumlarda bir CI/CD işlem hattı çalıştırılır ve kod başarıyla dağıtılır, ancak tüm bağımlılık kitaplıklarını yüklemekten sorumlu olan requirements.txt dosyası yürütülmüyor.

Bağımlılıkları yüklemek için App Service dağıtım görevinde bir dağıtım sonrası betiği kullanın. Aşağıdaki örnek, dağıtım sonrası betiğinde kullanmanız gereken komutu gösterir. Senaryonuz için betiği güncelleştirebilirsiniz.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Hizmet Bağlantısı ile ilgili sorunlar

Hizmet bağlantılarıyla ilgili sorunları gidermek için bkz . Hizmet bağlantısı sorunlarını giderme.

İşlem hattı aracıdan duymayı durdurdu

İşlem hattınız gibi We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.bir iletiyle başarısız olursa, aracı makinesinin kaynaklarının tükenip bitmediğini görmek için aracının kaynak kullanımını denetleyin. Sprint 228'den başlayarak Azure Pipelines günlükleri her adım için kaynak kullanım ölçümleri içerir.

Azure DevOps Services kullanırken ayrıntılı günlükleri etkinleştirerek günlüklerde disk kullanımı, bellek kullanımı ve CPU kullanımı gibi kaynak kullanımını görebilirsiniz. İşlem hattı tamamlandığında, günlüklerde her adım için Agent environment resources giriş arayın.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Ek kaynak kullanım günlüklerini yakalama hakkında bilgi için bkz . Kaynak kullanımı ayrıntılarını yakalama.

Depolama Gezgini'nin .css ve .js gibi statik içerikleri Azure DevOps'tan Azure Pipelines aracılığıyla statik bir web sitesine dağıtmasını sağlama

Bu senaryoda, web sitesine içerik yüklemek için Azure Dosya Kopyalama görevini kullanabilirsiniz. İçeriği web kapsayıcısına yüklemek için İçerik yükleme bölümünde açıklanan araçlardan herhangi birini kullanabilirsiniz.

Sonraki adımlar

• Günlükleri gözden geçirme