Azure Pipelines - Sprint 195 Güncelleştirmesi

Özellikler

Görev için otomatik yeniden denemeler

İşlem hattında zaman zaman başarısız olan bir istikrarsız göreviniz olduğunda, başarılı olması için işlem hattını yeniden çalıştırmanız gerekebilir. Çoğu durumda, gevşek bir görevi veya betiği ele almak için en iyi yol, görevin veya betiğin kendisini düzeltmektir. Örneğin, test göreviniz, kararsız testler nedeniyle işlem hattında başarısız olursa, bu testleri düzeltmek ve onları daha güvenilir hale getirmek her zaman iyi bir fikirdir. Benzer şekilde, betiğiniz arada bir başarısız olursa, örneğin betik içinde yeniden denemeler yaparak betiği düzeltmek daha iyidir.

Ancak, görevi yeniden denemek isteyebileceğiniz bazı durumlar vardır. Bunun için yaygın bir kullanım örneği, bir paketi (örneğin, NuGet, npm vb.) indiren bir görevdir. Bu görevlerin ağ hatalarına ve paket barındırma sunucularında geçici hatalara karşı duyarlı olduğunu sıklıkla gözlemledik. İşlem hattının tamamını yeniden başlatmak zorunda kalmadan bu tür başarısız görevleri otomatik olarak yeniden denemenin daha iyi olacağına ilişkin geri bildiriminizi aldık.

Geri bildirimlerinize dayanarak, işlem hattında bir görevi başarısız olduğunda otomatik olarak yeniden denemeye yönelik bir özellik ekledik. YAML işlem hatlarını kullanıyorsanız, bu girişi aşağıdaki gibi ayarlayabilirsiniz:

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Klasik derleme veya yayın işlem hatlarını kullanırken, bu özelliği görevin denetim seçenekleri altında ayarlayabilirsiniz.

Yeniden denemeler kullanılırken dikkate almaları gereken birkaç nokta şunlardır:

  • Başarısız olan görev hemen yeniden denendi.
  • Görevin idempotentliği hakkında bir varsayım yoktur. Görevin yan etkileri varsa (örneğin, kısmen bir dış kaynak oluşturduysa), ikinci kez çalıştırıldığında başarısız olabilir.
  • Göreve sunulan yeniden deneme sayısı hakkında hiçbir bilgi yok.
  • Görev günlüklerine yeniden denenmeden önce başarısız olduğunu belirten bir uyarı eklenir.
  • Bir görevi yeniden deneme girişimlerinin tümü kullanıcı arabiriminde aynı görev düğümünün bir parçası olarak gösterilir.

Uyarı

Aracı sürüm 2.194.0 veya üzerini gerektirir. Aracısız görevler için desteklenmez.

Başka bir görevden gelen girdileri bir dekoratörde tüketin

Yakın zamanda, bir görevi işlem hattındaki başka bir hedef görevden önce otomatik olarak bir işlem hattına ekleme özelliği ekledik. Şimdi hedef görevin giriş parametrelerini kullanarak eklenen görevi özelleştirmenize izin vererek bu özelliği geliştiriyoruz. Bunu yapmak için bir dekoratörün yazım söz dizimi şöyledir:

{
    "contributions": [
        {
            "id": <my-required-task>,
            "type": "ms.azure-pipelines.pipeline-decorator",
            "targets": [
                "ms.azure-pipelines-agent-job.pre-task-tasks",
                "ms.azure-pipelines-agent-job.post-task-tasks"
            ],
            "properties": {
                "template": "my-decorator.yml",
                "targettask": <target-task-id>,
                "targettaskinputs": ["<name of input>"]
            }
        }
    ],
    ...
}

Bu özellik, yalnızca ekleme hedefi olarak pre-task-tasks veya post-task-tasks kullandığınızda ve katkının özellikler bölümünde targettask belirttiğinizde çalışır. Daha sonra adlı targettaskinputs ek bir özellik ekleyebilir ve hedef görev tarafından kabul edilen giriş parametresi adlarının listesini belirtebilirsiniz. Bu girişler artık eklenen görevin kullanımına sunulmuştur.

Böyle bir senaryo tarafından gerçekleştirilebilecek yaygın bir kullanım örneği aşağıdaki gibidir. Bir yapının yayımladığı yapıtın adını otomatik olarak loglayacak bir görev entegre etmek istediğinizi varsayalım. Eserin adı PublishBuildArtifacts görevine bir girdidir. Eklenen göreviniz artık aynı giriş parametresini alabilir ve günlüğe kaydetmek için kullanabilir.

Hizmet bağlantıları kullanım geçmişinde iyileştirmeler

İşlem hattı bir hizmet bağlantısı kullandığında, bu kullanım bağlantının geçmişine kaydedilir. Hizmet bağlantısının yöneticileri, proje ayarlarına gidip uygun hizmet bağlantısını seçerek kullanım geçmişini gözden geçirebilir. Bu güncelleştirmeyle düzeltilen hizmet bağlantılarının kullanım geçmişiyle ilgili bazı sorunlar vardı. Düzeltmeler şunlardır:

  • Bir dağıtım işinde (normal bir iş yerine) bir hizmet bağlantısı kullanıldığında, bu kullanım günlüğe kaydedilmedi.
  • İşlem hattının birden çok aşamasında birden çok hizmet bağlantısı kullandıysanız, bazı aşamalar atlanmış olsa bile tüm hizmet bağlantıları kullanım geçmişinde bir kayıt gösterir.

Klasik işlem hatları için varsayılan aracı belirtimi artık Windows-2019'dur

Son sürüm notlarında, barındırılan görüntüler için bir kullanımdan kaldırma zamanlaması duyurusu vs2017-win2016 yaptık. Buna hazırlanırken, Klasik işlem hatlarında yeni hatlar oluştururken varsayılan temsilci belirtimini windows-2019 olarak değiştiriyoruz.

Aracı Belirtimi

Sonraki Adımlar

Uyarı

Bu özellikler önümüzdeki iki-üç hafta içinde kullanıma sunulacaktır.

Azure DevOps'a gidin ve bir göz atın.

Geri bildirim sağlama

Bu özellikler hakkında düşüncelerinizi duymak isteriz. Bir sorunu bildirmek veya öneri sağlamak için yardım menüsünü kullanın.

Öneride bulunma

Stack Overflow'da topluluk tarafından öneriler ve sorularınıza yanıt alabilirsiniz.