Aracılığıyla paylaş

Azure Repos Git veya TFS Git depoları oluşturma

  • Makale

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

Azure Pipelines, her çekme isteğini otomatik olarak derleyip doğrulayabilir ve Azure Repos Git deponuza işleyebilir.

Derlemek için bir depo seçin

Önce bir depo ve ardından bu depoda bir YAML dosyası seçerek yeni bir işlem hattı oluşturursunuz. YAML dosyasının bulunduğu depoya depo adı self verilir. Varsayılan olarak bu, işlem hattınızın oluşturduğu depodur.

İşlem hattınızı daha sonra farklı bir depoya veya birden çok depoya göz atacak şekilde yapılandırabilirsiniz. Bunun nasıl yapılacağını öğrenmek için bkz . çoklu depo kullanıma alma.

Derlemelerini tetikleyebilmek ve derlemeler sırasında kodlarını getirmek için Azure Pipelines'a depolarınıza erişim verilmelidir. Normalde bir işlem hattının aynı projedeki depolara erişimi vardır. Ancak, farklı bir projedeki depolara erişmek istiyorsanız, iş erişim belirteçlerine verilen izinleri güncelleştirmeniz gerekir.

CI tetikleyicileri

Sürekli tümleştirme (CI) tetikleyicileri, belirtilen dallara güncelleştirme gönderdiğinizde veya belirtilen etiketleri her gönderdiğinizde işlem hattının çalışmasına neden olur.

Azure DevOps sprint 227'de tanıtılan Örtük YAML CI tetikleyicisini devre dışı bırak ayarı etkinleştirilmediği sürece YAML işlem hatları varsayılan olarak tüm dallarda ci tetikleyicisi ile yapılandırılır. Zımni YAML CI tetikleyicisini devre dışı bırak ayarı kuruluş düzeyinde veya proje düzeyinde yapılandırılabilir. Örtük YAML CI tetikleyicisini devre dışı bırak ayarı etkinleştirildiğinde, YAML işlem hattının bir trigger bölümü yoksa YAML işlem hatları için CI tetikleyicileri etkinleştirilmez. Varsayılan olarak, Örtük YAML CI tetikleyicisini devre dışı bırak etkin değildir.

Dallar

Basit bir söz dizimi ile hangi dalların CI tetikleyicileri alabileceğini denetleyebilirsiniz:

trigger:
- main
- releases/*

Dalın tam adını (örneğin, main) veya joker karakteri (örneğin, releases/*) belirtebilirsiniz. Joker karakter söz dizimi hakkında bilgi için bkz. Joker karakterler.

Not

Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetikledikten sonra) tetikleyicilerde değişkenleri kullanamazsınız.

Not

YAML dosyalarını yazmak için şablonlar kullanıyorsanız, tetikleyicileri yalnızca işlem hattı için ana YAML dosyasında belirtebilirsiniz. Şablon dosyalarında tetikleyici belirtemezsiniz.

veya batchkullanan exclude daha karmaşık tetikleyiciler için, aşağıdaki örnekte gösterildiği gibi tam söz dizimini kullanmanız gerekir.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Yukarıdaki örnekte, herhangi bir yayın dalında veya dalında bir değişiklik gönderildiğinde main işlem hattı tetiklenir. Ancak, ile oldbaşlayan bir yayınlar dalında değişiklik yapıldığında tetiklenmez.

Yan tümcesi olmayan bir exclude include yan tümce belirtirseniz, yan tümcesinde belirtmeye include * eşdeğerdir.

Listelerde dal adlarını belirtmeye branches ek olarak, aşağıdaki biçimi kullanarak tetikleyicileri etiketlere göre de yapılandırabilirsiniz:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Herhangi bir tetikleyici belirtmediyseniz ve Zımni YAML CI tetikleyicisini devre dışı bırak ayarı etkinleştirilmediyse, varsayılan değer şöyle yazarsınız:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Önemli

Bir tetikleyici belirttiğinizde, varsayılan örtük tetikleyicinin yerini alır ve yalnızca açıkça dahil edilecek şekilde yapılandırılmış dallara gönderildiğinde işlem hattı tetiklenir. Eklemeler önce işlenir ve ardından dışlamalar bu listeden kaldırılır.

CI çalıştırmalarını toplu olarak oluşturma

Değişiklikleri sık sık karşıya yükleyen çok sayıda ekip üyeniz varsa, başlattığınız çalıştırma sayısını azaltmak isteyebilirsiniz. bir işlem hattı çalışırken olarak ayarlarsanız batch true, sistem çalıştırma tamamlanana kadar bekler, ardından henüz oluşturulmamış tüm değişikliklerle başka bir çalıştırma başlatır.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Not

batch depo kaynak tetikleyicilerinde desteklenmez.

Bu örneği netleştirmek için yukarıdaki işlem hattının çalışmasına bir göndermenin A main neden olduğunu düşünelim. İşlem hattı çalışırken depoya ek gönderimler B yapılır ve C gerçekleşir. Bu güncelleştirmeler yeni bağımsız çalıştırmaları hemen başlatmaz. Ancak ilk çalıştırma tamamlandıktan sonra, bu noktaya kadar tüm gönderimler birlikte toplu olarak yapılır ve yeni bir çalıştırma başlatılır.

Not

İşlem hattının birden çok işi ve aşaması varsa, ikinci çalıştırma başlamadan önce ilk çalıştırmanın tüm işlerini ve aşamalarını tamamlayarak veya atlayarak terminal durumuna ulaşması gerekir. Bu nedenle, bu özelliği birden çok aşamaya veya onaya sahip bir işlem hattında kullanırken dikkatli olmanız gerekir. Bu gibi durumlarda derlemelerinizi toplu olarak işlemek isterseniz, CI/CD işleminizi biri derleme (toplu işlem ile) ve diğeri dağıtımlar için olmak üzere iki işlem hattına bölmeniz önerilir.

Yollar

Dahil etmek veya dışlamak için dosya yollarını belirtebilirsiniz.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Yolları belirtirken, Azure DevOps Server 2019.1 veya daha düşük bir sürümünü kullanıyorsanız tetiklenecek dalları açıkça belirtmeniz gerekir. İşlem hattını yalnızca yol filtresiyle tetikleyemezsiniz; Ayrıca bir dal filtresine sahip olmanız ve yol filtresiyle eşleşen değiştirilen dosyaların dal filtresiyle eşleşen bir daldan olması gerekir. Azure DevOps Server 2020 veya daha yeni bir sürümü kullanıyorsanız, yol filtresiyle birlikte tüm dallara filtre uygulamak için atlayabilirsiniz branches .

Yol filtreleri için joker karakterler desteklenir. Örneğin, ile eşleşen src/app/**/myapp*tüm yolları ekleyebilirsiniz. Joker karakterlerini (**, *veya ?) yol filtrelerini belirtirken) kullanabilirsiniz.

  • Yollar her zaman deponun köküne göre belirtilir.
  • Yol filtreleri ayarlamazsanız, deponun kök klasörü varsayılan olarak örtük olarak eklenir.
  • Bir yolu dışlarsanız, daha derin bir klasöre nitelemediğiniz sürece bu yolu da ekleyemezsiniz. Örneğin ,araçları dışlarsanız /tools/trigger-runs-on-these ekleyebilirsiniz
  • Yol filtrelerinin sırası önemli değildir.
  • Git'teki yollar büyük/küçük harfe duyarlıdır. Gerçek klasörlerle aynı durumu kullandığınızdan emin olun.
  • Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetikledikten sonra) yollarda değişkenleri kullanamazsınız.

Etiketler

Önceki bölümde ele alınan listelerdeki branches etiketleri belirtmeye ek olarak, eklenecek veya dışlanan etiketleri doğrudan belirtebilirsiniz:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Herhangi bir etiket tetikleyicisi belirtmezseniz, etiketler varsayılan olarak işlem hatlarını tetiklemez.

Önemli

Etiketleri dal filtreleri ile birlikte belirtirseniz, dal filtresinin karşılanması veya etiket filtresinin karşılanması durumunda tetikleyici tetiklenir. Örneğin, gönderilen bir etiket dal filtresini karşılarsa, gönderme dal filtresini karşıladığı için etiket etiket filtresi tarafından dışlansa bile işlem hattı tetikler.

CI'yi geri çevirme

CI tetikleyicisini devre dışı bırakma

belirterek trigger: noneCI tetikleyicilerini tamamen devre dışı bırakabilirsiniz.

# A pipeline with no CI trigger
trigger: none

Önemli

Bir dala bir değişiklik gönderdiğinizde, bir CI çalıştırmasının başlatılıp başlatılmaması gerektiğini belirlemek için bu daldaki YAML dosyası değerlendirilir.

Tek tek göndermeler için CI atlanıyor

Ayrıca Azure Pipelines'a bir işlem hattını çalıştırmayı atlayıp göndermenin normalde tetikleyebileceğini de belirtebilirsiniz. Bir gönderimin parçası olan işlemelerden herhangi birinin iletisine dahil ***NO_CI*** edin; Azure Pipelines bu gönderim için CI çalıştırmayı atlar.

Ayrıca Azure Pipelines'a bir işlem hattını çalıştırmayı atlayıp göndermenin normalde tetikleyebileceğini de belirtebilirsiniz. Bir gönderimin parçası olan işlemelerin iletisine veya açıklamasına dahil [skip ci] edin; Azure Pipelines bu gönderim için CI çalıştırmayı atlar. Aşağıdaki çeşitlemelerden herhangi birini de kullanabilirsiniz.

  • [skip ci] veya [ci skip]
  • skip-checks: true veya skip-checks:true
  • [skip azurepipelines] veya [azurepipelines skip]
  • [skip azpipelines] veya [azpipelines skip]
  • [skip azp] veya [azp skip]
  • ***NO_CI***

Koşullarda tetikleyici türünü kullanma

Çalıştırmayı başlatan tetikleyici türüne bağlı olarak işlem hattınızda farklı adımları, işleri veya aşamaları çalıştırmak yaygın bir senaryodur. Bunu sistem değişkenini Build.Reasonkullanarak yapabilirsiniz. Örneğin, çekme isteği doğrulamalarının dışında tutmak için adımınıza, işinize veya aşamanıza aşağıdaki koşulu ekleyin.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Yeni dallar oluşturulduğunda tetikleyicilerin davranışı

Aynı depo için birden çok işlem hattı yapılandırmak yaygın bir durumdur. Örneğin, uygulamanızın belgelerini oluşturmak için bir işlem hattınız ve kaynak kodu oluşturmak için başka bir işlem hattınız olabilir. CI tetikleyicilerini bu işlem hatlarının her birinde uygun dal filtreleri ve yol filtreleri ile yapılandırabilirsiniz. Örneğin, klasöre bir güncelleştirme gönderdiğinizde bir işlem hattının docs tetiklenmesi ve uygulama kodunuz için bir güncelleştirme gönderdiğinizde tetiklenmesi için başka bir işlem hattı isteyebilirsiniz. Bu gibi durumlarda, yeni bir dal oluşturulduğunda işlem hatlarının nasıl tetiklendiğinden anlamanız gerekir.

Deponuza yeni bir dal (dal filtreleri ile eşleşen) gönderdiğinizde davranış şöyledir:

  • İşlem hattınızda yol filtreleri varsa, yalnızca yeni dalda bu yol filtresiyle eşleşen dosyalarda değişiklikler olduğunda tetiklenir.
  • İşlem hattınızda yol filtreleri yoksa, yeni dalda değişiklik olmasa bile tetiklenir.

Joker karakterler

Dal, etiket veya yol belirtirken tam bir ad veya joker karakter kullanabilirsiniz. Joker karakter desenleri sıfır veya daha fazla karakter eşleştirmeye ve ? tek bir karakterle eşleşmeye olanak sağlar*.

  • Deseninizi bir YAML işlem hattında ile * başlatırsanız, deseni gibi "*-releases"tırnak içine sarmalamanız gerekir.
  • Dallar ve etiketler için:
    • Joker karakter desenin herhangi bir yerinde görünebilir.
  • Yollar için:
    • Azure DevOps Services dahil olmak üzere Azure DevOps Server 2022 ve üzeri sürümlerde yol deseni içinde herhangi bir yerde joker karakter görüntülenebilir ve veya ?kullanabilirsiniz*.
    • Azure DevOps Server 2020 ve daha düşük sürümlerde son karakter olarak ekleyebilirsiniz * , ancak dizin adını tek başına belirtmekten farklı bir şey yapmaz. Yol filtresinin ortasına eklemeyebilir * ve kullanamazsınız?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Çekme isteği tetikleyicileri

Çekme isteği (PR) tetikleyicileri, çekme isteği açtığınızda veya değişiklikleri gönderdiğinizde işlem hattının çalışmasına neden olur. Azure Repos Git'te bu işlev dal ilkeleri kullanılarak uygulanır. Çekme isteği doğrulamasını etkinleştirmek için, istenen dalın dal ilkelerine gidin ve bu dal için Derleme doğrulama ilkesini yapılandırın. Daha fazla bilgi için bkz . Dal ilkelerini yapılandırma.

Açık bir çekme isteğiniz varsa ve değişiklikleri kaynak dalına gönderdiyseniz, birden çok işlem hattı çalıştırılabilir:

  • Hedef dalın derleme doğrulama ilkesi tarafından belirtilen işlem hatları, iletileri veya açıklamaları (veya değişkenlerinden herhangi birini) içeren [skip ci] gönderilen işlemeler olup olmadığına bakılmaksızın, birleştirme işlemesinde (çekme isteğinin kaynak ve hedef dalları arasındaki birleştirilmiş kod) çalışır.
  • İletileri veya açıklamaları (veya değişkenlerinden herhangi birini) içeren [skip ci] gönderilen işlemeler yoksa, çekme isteğinin kaynak dalında yapılan değişikliklerle tetiklenen işlem hatları. En az bir gönderilen işleme içeriyorsa [skip ci], işlem hatları çalışmaz.

Son olarak, çekme isteğini birleştirdikten sonra Azure Pipelines, birleştirilmiş işlemelerin iletilerinden veya açıklamalarından bazıları (veya değişkenlerinden herhangi birini) içerse [skip ci] bile hedef dala göndermeler tarafından tetiklenen CI işlem hatlarını çalıştırır.

Not

Azure Repos Git deposu için doğrulama derlemelerini yapılandırmak için, projesinin proje yöneticisi olmanız gerekir.

Not

Taslak çekme istekleri , dal ilkesi yapılandırsanız bile işlem hattını tetiklemez.

Çatallardan gelen katkıları doğrulama

Azure Repos çatallarından çekme istekleri oluşturmak, aynı depo veya proje içinde çekme istekleri oluşturmaktan farklı değildir. Çatalları yalnızca projenizin parçası olduğu kuruluşta oluşturabilirsiniz.

İş yetkilendirme kapsamını sınırlama

Azure Pipelines, işlem hatlarınızın birlikte çalıştığı iş yetkilendirme kapsamını yapılandırmak için çeşitli güvenlik ayarları sağlar.

İş yetkilendirme kapsamını geçerli projeyle sınırla

Azure Pipelines, geçerli proje ayarlarıyla iş yetkilendirme kapsamını sınırla iki tane sağlar:

  • Yayın dışı işlem hatları için iş yetkilendirme kapsamını geçerli projeyle sınırla - Bu ayar YAML işlem hatları ve klasik derleme işlem hatları için geçerlidir. Bu ayar klasik yayın işlem hatları için geçerli değildir.
  • yayın işlem hatları için iş yetkilendirme kapsamını geçerli projeyle sınırla - Bu ayar yalnızca klasik yayın işlem hatları için geçerlidir.

İşlem hattı türü için ilgili ayar etkinleştirilmediği sürece işlem hatları koleksiyon kapsamlı erişim belirteçleriyle çalışır. İş yetkilendirme kapsamını sınırla ayarları, geçerli projeye tüm işlem hatları için erişim kapsamını azaltmanıza olanak sağlar. Kuruluşunuzdaki farklı bir projede yer alan bir Azure Repos Git deposuna erişiyorsanız bu işlem hattınızı etkileyebilir.

Azure Repos Git deponuz işlem hattınızdan farklı bir projedeyse ve işlem hattı türünüz için İş yetkilendirme kapsamını sınırla ayarı etkinleştirildiyse, işlem hattınızın derleme hizmeti kimliğine ikinci projeye izin vermelisiniz. Daha fazla bilgi için bkz . Derleme hizmeti hesabı izinlerini yönetme.

Azure Pipelines, işlem hatlarınızın birlikte çalıştığı iş yetkilendirme kapsamını yapılandırmak için bir güvenlik ayarı sağlar.

  • İş yetkilendirme kapsamını geçerli projeyle sınırla - Bu ayar YAML işlem hatları ve klasik derleme işlem hatları için geçerlidir. Bu ayar klasik yayın işlem hatları için geçerli değildir.

İş yetkilendirme kapsamını geçerli projeyle sınırla etkinleştirilmediği sürece işlem hatları koleksiyon kapsamlı erişim belirteçleriyle çalışır. Bu ayar, geçerli projeye tüm işlem hatları için erişim kapsamını azaltmanıza olanak tanır. Kuruluşunuzdaki farklı bir projede yer alan bir Azure Repos Git deposuna erişiyorsanız bu işlem hattınızı etkileyebilir.

Azure Repos Git deponuz işlem hattınızdan farklı bir projedeyse ve İş yetkilendirme kapsamını sınırla ayarı etkinse, işlem hattınızın derleme hizmeti kimliğine ikinci projeye izin vermelisiniz. Daha fazla bilgi için bkz. İş yetkilendirme kapsamı.

İş yetkilendirme kapsamını sınırlama hakkında daha fazla bilgi için bkz. İş erişim belirteçlerini anlama.

İş yetkilendirme kapsamını başvuruda bulunan Azure DevOps depoları ile sınırlandırma

İş yetkilendirme kapsamını başvuruda bulunan Azure DevOps depolarıyla sınırlama özelliği etkinleştirilmediği sürece işlem hatları, önceki İş yetkilendirme kapsamını geçerli projeyle sınırla bölümünde açıklandığı gibi yetkili projelerdeki tüm Azure DevOps depolarına erişebilir. Bu seçenek etkinleştirildiğinde, tüm işlem hatları için erişim kapsamını yalnızca bu depoyu kullanan işlem hattı işindeki bir checkout adım veya uses deyim tarafından açıkça başvuruda bulunan Azure DevOps depolarına azaltabilirsiniz.

Bu ayarı yapılandırmak için Kuruluş ayarlarından veya Proje ayarlarından İşlem Hatları, Ayarlar'a gidin. Kuruluş düzeyinde etkinleştirilirse, ayar gri görünür ve proje ayarları düzeyinde kullanılamaz.

İş yetkilendirme kapsamını başvuruda bulunan Azure DevOps depolarıyla sınırla etkinleştirildiğinde, YAML işlem hatlarınızın işlem hattında depoyu kullanan işte kullanıma alma adımı olarak kullanmak istediğiniz Azure Repos Git depolarına açıkça başvurması gerekir. Azure Repos Git deposu için betik oluşturma görevlerini ve git komutlarını kullanarak kod getiremezsiniz, ancak bu depoya açıkça başvurulmaz.

İş yetkilendirme kapsamını başvurulmuş Azure DevOps depolarıyla sınırla etkinleştirildiğinde işlem hattınızda kullanmadan önce bir Azure Repos Git deposuna açıkça başvurmanız gerekmeyen birkaç özel durum vardır.

  • İşlem hattınızda açık bir kullanıma alma adımı yoksa, bir adımınız var checkout: self demektir ve self depo kullanıma alınmış demektir.
  • Ortak projedeki bir depoda salt okunur işlemler gerçekleştirmek için betik kullanıyorsanız, bir checkout adımda ortak proje deposuna başvurmanız gerekmez.
  • Depoya pat gibi kendi kimlik doğrulamasını sağlayan bir betik kullanıyorsanız, bir checkout adımda bu depoya başvurmanız gerekmez.

Örneğin, İş yetkilendirme kapsamını başvuruda bulunan Azure DevOps depolarıyla sınırla etkinleştirildiğinde işlem hattınız kuruluşunuzdaki depodaysa FabrikamProject/Fabrikam ve depoyu kullanıma FabrikamProject/FabrikamTools almak için bir betik kullanmak istiyorsanız, bu depoya bir checkout adımda veya deyimiyle uses başvurmanız gerekir.

İşlem hattınızdaki depoyu FabrikamTools kullanıma alma adımı kullanarak zaten kullanıma aldıysanız, daha sonra bu depoyla etkileşime geçmek için betikleri kullanabilirsiniz.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Not

Birçok senaryoda çoklu depo kullanıma alma seçeneğinden yararlanılarak işlem hattınızdaki ek depoları kullanıma almak için betik kullanma gereksinimi ortadan kaldırılabilir. Daha fazla bilgi için bkz . İşlem hattınızdaki birden çok depoya göz atın.

YAML işlem hatlarındaki depolara erişimi koruma

İşlem hatları, YAML işlem hatlarındaki depolara erişimi koruma etkinleştirilmediği sürece, önceki İş yetkilendirme kapsamını geçerli projeyle sınırlama bölümünde açıklandığı gibi yetkili projelerdeki tüm Azure DevOps depolarına erişebilir. Bu seçenek etkinleştirildiğinde, tüm işlem hatları için erişim kapsamını yalnızca bu depoyu kullanan işlem hattı işindeki bir checkout adım veya uses deyim tarafından açıkça başvuruda bulunan Azure DevOps depolarına azaltabilirsiniz.

Bu ayarı yapılandırmak için Kuruluş ayarlarından veya Proje ayarlarından İşlem Hatları, Ayarlar'a gidin. Kuruluş düzeyinde etkinleştirilirse, ayar gri görünür ve proje ayarları düzeyinde kullanılamaz.

Önemli

Mayıs 2020'de oluşturulan yeni kuruluşlar ve projeler için YAML işlem hatlarındaki depolara erişimi koruma varsayılan olarak etkindir. YAML işlem hatlarındaki depolara erişimi koruma etkinleştirildiğinde, YAML işlem hatlarınızın depoyu kullanan işte kullanıma alma adımı olarak işlem hattında kullanmak istediğiniz Azure Repos Git depolarına açıkça başvurması gerekir. Azure Repos Git deposu için betik oluşturma görevlerini ve git komutlarını kullanarak kod getiremezsiniz, ancak bu depoya açıkça başvurulmaz.

YAML işlem hatlarındaki depolara erişimi koruma etkinleştirildiğinde işlem hattınızda kullanmadan önce bir Azure Repos Git deposuna açıkça başvurmanız gerekmeyen birkaç özel durum vardır.

  • İşlem hattınızda açık bir kullanıma alma adımı yoksa, bir adımınız var checkout: self demektir ve self depo kullanıma alınmış demektir.
  • Ortak projedeki bir depoda salt okunur işlemler gerçekleştirmek için betik kullanıyorsanız, bir checkout adımda ortak proje deposuna başvurmanız gerekmez.
  • Depoya pat gibi kendi kimlik doğrulamasını sağlayan bir betik kullanıyorsanız, bir checkout adımda bu depoya başvurmanız gerekmez.

Örneğin, YAML işlem hatlarındaki depolara erişimi koruma etkinleştirildiğinde, işlem hattınız kuruluşunuzdaki depodaysa FabrikamProject/Fabrikam ve depoyu kullanıma FabrikamProject/FabrikamTools almak için bir betik kullanmak istiyorsanız, bu depoya bir checkout adımda veya deyimiyle uses başvurmanız gerekir.

İşlem hattınızdaki depoyu FabrikamTools kullanıma alma adımı kullanarak zaten kullanıma aldıysanız, daha sonra bu depoyla etkileşime geçmek için betikleri kullanabilirsiniz.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Not

Birçok senaryoda çoklu depo kullanıma alma seçeneğinden yararlanılarak işlem hattınızdaki ek depoları kullanıma almak için betik kullanma gereksinimi ortadan kaldırılabilir. Daha fazla bilgi için bkz . İşlem hattınızdaki birden çok depoya göz atın.

Kullanıma Al

İşlem hattı tetiklendiğinde Azure Pipelines kaynak kodunuzu Azure Repos Git deposundan çeker. Bunun nasıl gerçekleştiğini çeşitli yönleriyle denetleyebilirsiniz.

Not

İşlem hattınıza bir kullanıma alma adımı eklediğinizde şu komutu çalıştırırız: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Bu, gereksinimlerinizi karşılamıyorsa, tarafından yerleşik kullanıma checkout: none almayı dışlama seçeneğini belirleyebilir ve ardından kendi ödemenizi gerçekleştirmek için bir betik görevi kullanabilirsiniz.

Tercih edilen Git sürümü

Windows aracısı kendi Git kopyasıyla birlikte gelir. Dahil edilen kopyayı kullanmak yerine kendi Git'inizi sağlamayı tercih ediyorsanız olarak ayarlayın System.PreferGitFromPath true. Bu ayar Windows olmayan aracılarda her zaman geçerlidir.

Kullanıma alma yolu

Tek bir depoya göz atıyorsanız, kaynak kodunuz varsayılan olarak adlı sbir dizinde kullanıma alınır. YAML işlem hatları için, ile pathbelirterek checkout bunu değiştirebilirsiniz. Belirtilen yol ile $(Agent.BuildDirectory)görelidir. Örneğin: kullanıma alma yolu değeri mycustompath ve $(Agent.BuildDirectory) ise C:\agent\_work\1, kaynak kodu içine C:\agent\_work\1\mycustompathkullanıma alınır.

Birden çok adım kullanıyor ve birden çok checkout depoyu kullanıma alıp kullanarak klasörü pathaçıkça belirtmiyorsanız, her depo depodan sonra adlı alt klasörüne s yerleştirilir. Örneğin ve codeadlı tools iki depoyu kullanıma alırsanız kaynak kodu ve C:\agent\_work\1\s\codeiçinde kullanıma C:\agent\_work\1\s\tools alınır.

Lütfen, kullanıma alma yolu değerinin üzerinde $(Agent.BuildDirectory)herhangi bir dizin düzeyine çıkacak şekilde ayarlanamayacağını, bu nedenle path\..\anotherpath geçerli bir kullanıma alma yolu (örneğin C:\agent\_work\1\anotherpath) ile sonuçlanacağını, ancak gibi ..\invalidpath bir değerin (örneğin C:\agent\_work\invalidpath) ayarlanamayacağını unutmayın.

bu ayarı işlem hattınızın Kullanıma Alma adımında yapılandırabilirsinizpath.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Alt modüller

Alt modüllerden dosya indirmek istiyorsanız, bu ayarı işlem hattınızın Kullanıma Alma adımında yapılandırabilirsinizsubmodules.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Derleme işlem hattı, Git alt modüllerinizi şunlar olduğu sürece kullanıma alır:

  • Kimliği doğrulanmamış: Kopyalamak veya getirmek için kimlik bilgisi gerektirmeyen genel, kimliği doğrulanmamış bir depo.

  • Kimlik doğrulaması:

    • Yukarıda belirtilen Azure Repos Git deposuyla aynı projede yer alır. Aracı tarafından ana depodan kaynakları almak için kullanılan kimlik bilgileri, alt modül kaynaklarını almak için de kullanılır.

    • Ana depoya göre bir URL kullanılarak eklenir. Örneğin:

      • Bunun kullanıma alınması gerekir: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        Bu örnekte alt modül, aynı Azure DevOps kuruluşundaki ancak farklı bir projedeki (FabrikamFiberProject) bir depoya (FabrikamFiber) başvurur. Aracı tarafından ana depodan kaynakları almak için kullanılan kimlik bilgileri, alt modül kaynaklarını almak için de kullanılır. Bunun için iş erişim belirtecinin ikinci projedeki depoya erişimi olması gerekir. İş erişim belirtecini yukarıdaki bölümde açıklandığı gibi kısıtladıysanız, bunu yapamazsınız. İş erişim belirtecinin ikinci projedeki depoya erişmesine izin vermek için (a) ikinci projedeki proje derleme hizmeti hesabına açıkça erişim izni verebilir veya (b) kuruluşun tamamı için proje kapsamlı belirteçler yerine koleksiyon kapsamlı erişim belirteçlerini kullanabilirsiniz. Bu seçenekler ve bunların güvenlik etkileri hakkında daha fazla bilgi için bkz . Erişim depoları, yapıtlar ve diğer kaynaklar.

      • Bu, kullanıma alınmaz: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Kullanıma Alma alt modülleri seçeneğini kullanmaya alternatif

Bazı durumlarda Kullanıma Alma alt modülleri seçeneğini kullanamazsınız. Alt modüllere erişmek için farklı bir kimlik bilgileri kümesinin gerekli olduğu bir senaryonuz olabilir. Bu durum, örneğin ana deponuz ve alt modül depolarınız aynı Azure DevOps kuruluşunda depolanmadıysa veya iş erişim belirtecinizin farklı bir projedeki depoya erişimi yoksa oluşabilir.

Kullanıma Alma alt modülleri seçeneğini kullanamıyorsanız , bunun yerine alt modülleri getirmek için özel bir betik adımı kullanabilirsiniz. İlk olarak, bir kişisel erişim belirteci (PAT) alın ve ön ekini ekleyin pat:. Ardından, temel bir kimlik doğrulama belirteci oluşturmak için bu ön ekli dizeyi base64 ile kodlayın . Son olarak, bu betiği işlem hattınıza ekleyin:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

"<BASE64_ENCODED_STRING>" yerine Base64 kodlu "pat:token" dizenizi değiştirmeyi unutmayın.

Oluşturduğunuz temel kimlik doğrulama belirtecini depolamak için projenizde veya derleme işlem hattınızda gizli dizi değişkeni kullanın. Yukarıdaki Git komutunda gizli diziyi doldurmak için bu değişkeni kullanın.

Not

S: Aracıda neden Git kimlik bilgisi yöneticisi kullanamıyorum? Y: Alt modül kimlik bilgilerini özel derleme aracınızda yüklü bir Git kimlik bilgisi yöneticisinde depolamak genellikle etkili olmaz. Kimlik bilgisi yöneticisi, alt modül her güncelleştirildiğinde kimlik bilgilerini yeniden girmenizi isteyebilir. Kullanıcı etkileşimi mümkün olmadığında otomatik derlemeler sırasında bu tercih edilmez.

Etiketleri eşitleme

Önemli

Eşitleme etiketleri özelliği Azure DevOps Server 2022.1 ve üzeri ile Azure Repos Git'te desteklenir.

Kullanıma alma adımı, Git deposunun içeriğini getirirken seçeneğini kullanır --tags . Bu, sunucunun hem tüm etiketleri hem de bu etiketler tarafından işaret edilen tüm nesneleri getirmesine neden olur. Bu, özellikle çok sayıda etiket içeren büyük bir deponuz varsa, işlem hattında görevi çalıştırma süresini artırır. Ayrıca, kullanıma alma adımı, sığ getirme seçeneğini etkinleştirdiğinizde bile etiketleri eşitler ve böylece amacını yenebilir. Git deposundan getirilen veya çekilen veri miktarını azaltmak için Microsoft, etiketleri eşitleme davranışını denetlemek için kullanıma alma seçeneği eklemiştir. Bu seçenek hem klasik hem de YAML işlem hatlarında kullanılabilir.

Bir depoyu kullanıma alırken etiketlerin eşitlenip eşitlenmeyeceği YAML'de özelliği ayarlanarak fetchTags ve kullanıcı arabiriminde Eşitleme etiketleri ayarı yapılandırılarak yapılandırılabilir.

bu ayarı işlem hattınızın Kullanıma Alma adımında yapılandırabilirsinizfetchTags.

YAML'de ayarı yapılandırmak için özelliğini ayarlayın fetchTags .

steps:
- checkout: self
  fetchTags: true

İşlem hattı ayarları kullanıcı arabirimindeki Etiketleri eşitle seçeneğini kullanarak da bu ayarı yapılandırabilirsiniz.

  1. YAML işlem hattınızı düzenleyin ve Diğer eylemler, Tetikleyiciler'i seçin.

    Diğer tetikleyiciler menüsünün ekran görüntüsü.

  2. YAML ve Kaynak al'ı seçin.

    Kaynakları al seçeneğinin ekran görüntüsü.

  3. Etiketleri eşitle ayarını yapılandırın.

    Etiketleri eşitle ayarının ekran görüntüsü.

Not

Adımınızda checkout açıkça ayarlarsanızfetchTags, bu ayar işlem hattı ayarları kullanıcı arabiriminde yapılandırılan ayara göre önceliklidir.

Varsayılan davranış

Not

Adımınızda checkout açıkça ayarlarsanızfetchTags, bu ayar işlem hattı ayarları kullanıcı arabiriminde yapılandırılan ayara göre önceliklidir.

Sığ getirme

Geçmişteki indirme hızını sınırlamak isteyebilirsiniz. Bu, etkili bir şekilde ile sonuçlanan bir sonuç olur git fetch --depth=n. Deponuz büyükse bu seçenek derleme işlem hattınızı daha verimli hale getirebilir. Deponuz uzun süredir kullanılıyorsa ve büyük boyutlu geçmişe sahipse büyük olabilir. Ayrıca büyük dosyaları ekleyip daha sonra sildiyseniz de büyük olabilir.

Önemli

Eylül 2022 Azure DevOps sprint 209 güncelleştirmesinin ardından oluşturulan yeni işlem hatlarında Sığ getirme varsayılan olarak etkindir ve 1 derinliğiyle yapılandırılır. Önceden varsayılan değer basit getirme değildi. İşlem hattınızı denetlemek için, aşağıdaki bölümde açıklandığı gibi işlem hattı ayarları kullanıcı arabiriminde Sığ getirme ayarını görüntüleyin.

bu ayarı işlem hattınızın Kullanıma Alma adımında yapılandırabilirsinizfetchDepth.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

İşlem hattı ayarları kullanıcı arabiriminde Sığ derinlik seçeneğini ayarlayarak getirme derinliğini de yapılandırabilirsiniz.

  1. YAML işlem hattınızı düzenleyin ve Diğer eylemler, Tetikleyiciler'i seçin.

    Diğer tetikleyiciler menüsünün ekran görüntüsü.

  2. YAML ve Kaynak al'ı seçin.

    Kaynakları al seçeneğinin ekran görüntüsü.

  3. Sığ getirme ayarını yapılandırın. Sığ getirme özelliğini devre dışı bırakmak için Sığ getirme'nin işaretini kaldırın veya sığ getirme özelliğini etkinleştirmek için kutuyu işaretleyin ve bir Derinlik girin.

    Seçeneklerin ekran görüntüsü.

Not

Adımınızda checkout açıkça ayarlarsanızfetchDepth, bu ayar işlem hattı ayarları kullanıcı arabiriminde yapılandırılan ayara göre önceliklidir. Ayar fetchDepth: 0 tüm geçmişi getirir ve Sığ getirme ayarını geçersiz kılar.

Bu durumlarda bu seçenek ağ ve depolama kaynaklarını korumanıza yardımcı olabilir. Ayrıca zaman kazandırabilir. Her zaman zaman tasarruf etmemesi, bazı durumlarda sunucunun belirttiğiniz derinlik için indirilmesi gereken işlemeleri hesaplamak için zaman harcaması gerekmesidir.

Not

İşlem hattı başlatıldığında, derlenen dal bir işleme kimliğine çözümlenir. Ardından aracı dalı getirir ve istenen işlemeyi denetler. Bir dalın işleme kimliğine çözümlenmesi ile aracının kullanıma alma işlemini gerçekleştirmesi arasında küçük bir pencere vardır. Dal hızla güncelleştirilir ve sığ getirme için çok küçük bir değer ayarlarsanız, aracı kullanıma almaya çalıştığında işleme mevcut olmayabilir. Böyle bir durumda sığ getirme derinliği ayarını artırın.

Kaynakları eşitleme

Yeni işlemeleri getirmeyi atlamak isteyebilirsiniz. Bu seçenek, aşağıdaki durumlarda yararlı olabilir:

  • Kendi özel seçeneklerinizi kullanarak Git başlatma, yapılandırma ve getirme.

  • Derleme işlem hattını kullanarak yalnızca sürüm denetimindeki koda bağımlı olmayan otomasyonu (örneğin bazı betikler) çalıştırın.

İşlem hattınızın Kullanıma Alma adımında Kaynakları eşitleme ayarını ayarlayarak checkout: noneyapılandırabilirsiniz.

steps:
- checkout: none  # Don't sync sources

Not

Bu seçeneği kullandığınızda aracı, depoyu temizleyen Git komutlarını çalıştırmayı da atlar.

Derlemeyi temizleme

Derleme çalışmadan önce şirket içinde barındırılan aracınızın çalışma dizinini temizlemenin farklı biçimlerini gerçekleştirebilirsiniz.

Genel olarak, şirket içinde barındırılan aracılarınızın daha hızlı performansı için depoyu temizlemeyin. Bu durumda, en iyi performansı elde etmek için, derlemek için kullandığınız görev veya aracın Herhangi bir Temiz seçeneğini devre dışı bırakarak artımlı olarak oluşturduğunuzdan emin olun.

Depoyu temizlemeniz gerekiyorsa (örneğin, önceki derlemedeki artık dosyaların neden olduğu sorunları önlemek için) seçenekleriniz aşağıdadır.

Not

Microsoft tarafından barındırılan bir aracı kullanıyorsanız temizleme işlemi etkili değildir çünkü her seferinde yeni bir aracı alırsınız.

bu ayarı işlem hattınızın Kullanıma Alma adımında yapılandırabilirsinizclean.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

clean derleme işlem hattına true ayarlandığında içindeki $(Build.SourcesDirectory)değişiklikleri geri alır. Daha açık belirtmek gerekirse, aşağıdaki Git komutları kaynağı getirmeden önce yürütülür.

git clean -ffdx
git reset --hard HEAD

Diğer seçenekler için bir İş ayarını yapılandırabilirsinizworkspace.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Bu, aşağıdaki temiz seçenekleri sağlar.

  • çıkışlar: Önceki kullanıma alma görevinde açıklanan temiz ayar ile aynı işlem, artı olarak: siler ve yeniden oluşturur $(Build.BinariesDirectory). ve $(Common.TestResultsDirectory) değerlerinin $(Build.ArtifactStagingDirectory) bu ayarlardan herhangi biri ne olursa olsun her derlemeden önce silindiğini ve yeniden oluşturduğunu unutmayın.

  • kaynaklar: öğesini siler ve yeniden oluşturur $(Build.SourcesDirectory). Bu, her derleme için yeni, yerel bir Git deposunun başlatılmasına neden olur.

  • all: siler ve yeniden oluşturur $(Agent.BuildDirectory). Bu, her derleme için yeni, yerel bir Git deposunun başlatılmasına neden olur.

Etiket kaynakları

Ekibinizin tamamlanan derlemeye her dosyanın hangi sürümünün dahil olduğunu kolayca belirlemesini sağlamak için kaynak kod dosyalarınızı etiketlemek isteyebilirsiniz. Kaynak kodun tüm derlemeler için mi yoksa yalnızca başarılı derlemeler için mi etiketleneceğini belirtme seçeneğiniz de vardır.

Bu ayarı şu anda YAML'de yapılandıramazsınız, ancak klasik düzenleyicide yapılandırabilirsiniz. YAML işlem hattını düzenlerken, YAML düzenleyicisi menüsünden Tetikleyiciler'i seçerek klasik düzenleyiciye erişebilirsiniz.

Git seçeneklerini yapılandırın, YAML.

Klasik düzenleyiciden YAML'yi seçin, Kaynakları al görevini seçin ve ardından istediğiniz özellikleri orada yapılandırın.

Klasik düzenleyiciden YAML > Kaynak al'ı seçin.

Etiket biçiminde, "Tümü" kapsamına sahip kullanıcı tanımlı ve önceden tanımlanmış değişkenleri kullanabilirsiniz. Mesela:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

İlk dört değişken önceden tanımlanmıştır. My.Variabledeğişkenler sekmesinde sizin tarafınızdan tanımlanabilir.

Derleme işlem hattı, kaynaklarınızı git etiketiyle etiketler.

Bazı derleme değişkenleri geçerli bir etiket olmayan bir değer verebilir. Örneğin ve gibi $(Build.RequestedFor) $(Build.DefinitionName) değişkenler boşluk içerebilir. Değer boşluk içeriyorsa etiket oluşturulmaz.

Kaynaklar derleme işlem hattınız tarafından etiketlendikten sonra, tamamlanan derlemeye Git başvurusunu refs/tags/{tag} içeren bir yapıt otomatik olarak eklenir. Bu, ekibinize ek izlenebilirlik ve derlemeden oluşturulan koda gitmek için daha kolay bir yol sağlar. etiketi, derleme tarafından üretildiği için derleme yapıtı olarak kabul edilir. Derleme el ile veya bekletme ilkesi aracılığıyla silindiğinde, etiket de silinir.

SSS

Azure Repos tümleştirmesi ile ilgili sorunlar üç kategoriye ayrılır:

  • Başarısız tetikleyiciler: Depoya güncelleştirme gönderdiğimde işlem hattım tetiklenmiyor.
  • Kullanıma alma başarısız oluyor: İşlem hattım tetikleniyor, ancak kullanıma alma adımında başarısız oluyor.
  • Yanlış sürüm: İşlem hattım çalışıyor, ancak kaynağın/YAML'nin beklenmeyen bir sürümünü kullanıyor.

Başarısız tetikleyiciler

CI/PR tetikleyicileriyle yeni bir YAML işlem hattı oluşturdum, ancak işlem hattı tetiklenmiyor.

Başarısız tetikleyicilerinizin sorunlarını gidermek için aşağıdaki adımların her birini izleyin:

  • YAML CI veya PR tetikleyicileriniz kullanıcı arabirimindeki işlem hattı ayarları tarafından geçersiz kılınıyor mu? İşlem hattınızı düzenlerken ... ve ardından Tetikleyiciler'i seçin.

    İşlem hattı ayarları kullanıcı arabirimi.

    Deponuz için kullanılabilir tetikleyici türleri (Sürekli tümleştirme veya Çekme isteği doğrulaması) için buradan YAML tetikleyicisini geçersiz kıl ayarını işaretleyin.

    Buradan YAML tetikleyicisi geçersiz kılın.

  • ÇEKME isteği tetikleyicisini YAML dosyasında mı yoksa deponun dal ilkelerinde mi yapılandırıyorsunuz? Azure Repos Git deposu için YAML dosyasında çekme isteği tetikleyicisi yapılandıramazsınız. Dal ilkelerini kullanmanız gerekir.

  • İşlem hattınız duraklatıldı mı yoksa devre dışı mı bırakıldı? İşlem hattının düzenleyicisini açın ve ardından denetlemek için Ayarlar'ı seçin. İşlem hattınız duraklatılmış veya devre dışı bırakılmışsa tetikleyiciler çalışmaz.

  • YAML dosyasını doğru dalda güncelleştirdiniz mi? Bir güncelleştirmeyi bir dala iletirseniz, CI davranışını aynı daldaki YAML dosyası yönetir. Bir güncelleştirmeyi bir kaynak dala iletirseniz, kaynak dalın hedef dalla birleştirilmesinden kaynaklanan YAML dosyası çekme isteği davranışını yönetir. Doğru daldaki YAML dosyasının gerekli CI veya PR yapılandırmasına sahip olduğundan emin olun.

  • Tetikleyiciyi doğru yapılandırdınız mı? BIR YAML tetikleyicisi tanımlarken dallar, etiketler ve yollar için hem include hem de exclude yan tümcelerini belirtebilirsiniz. include yan tümcesinin işlemenizin ayrıntılarıyla eşleştiğinden ve exclude yan tümcesinin bunları dışlamadığından emin olun. Tetikleyicilerin söz dizimini denetleyin ve doğru olduğundan emin olun.

  • Tetikleyiciyi veya yolları tanımlarken değişkenleri kullandınız mı? Bu desteklenmez.

  • YAML dosyanız için şablonları kullandınız mı? Öyleyse, tetikleyicilerinizin ana YAML dosyasında tanımlandığından emin olun. Şablon dosyalarının içinde tanımlanan tetikleyiciler desteklenmez.

  • Değişikliklerinizi iletmiş olduğunuz dalları veya yolları dışladiniz mi? Eklenen bir daldaki dahil edilen yola bir değişiklik göndererek test edin. Tetikleyicilerdeki yolların büyük/küçük harfe duyarlı olduğunu unutmayın. Tetikleyicilerdeki yolları belirtirken gerçek klasörlerinkilerle aynı büyük/küçük harf kullandığınızdan emin olun.

  • Yeni bir dal mı ittirdin? Bu durumda, yeni dal yeni bir çalıştırma başlatamayabilir. "Yeni dallar oluşturulduğunda tetikleyicilerin davranışı" bölümüne bakın.

CI veya PR tetikleyicilerim sorunsuz çalışıyor. Ama artık çalışmayı bıraktılar.

İlk olarak önceki sorudaki sorun giderme adımlarını izleyin. Ardından şu ek adımları izleyin:

  • Çekme isteğinizde birleştirme çakışmaları var mı? İşlem hattını tetiklemeyen bir çekme isteği için açın ve birleştirme çakışması olup olmadığını denetleyin. Birleştirme çakışmasını çözün.

  • Gönderme veya çekme isteği olaylarının işlenmesinde gecikme mi yaşıyorsunuz? Genellikle sorunun tek bir işlem hattına özgü olup olmadığını veya projenizdeki tüm işlem hatları veya depolar için ortak olup olmadığını görerek bunu doğrulayabilirsiniz. Depolardan herhangi birine gönderim veya çekme isteği güncelleştirmesi bu belirtiyi gösterirse, güncelleştirme olaylarını işlemede gecikmeler yaşıyor olabiliriz. Durum sayfamızda hizmet kesintisi yaşanıp karşılaşmadığımıza bakın. Durum sayfasında bir sorun görünüyorsa ekibimizin bu sorun üzerinde çalışmaya başlamış olması gerekir. Sorunla ilgili güncelleştirmeler için sayfayı sık sık denetleyin.

Kullanıcıların YAML dosyasını güncelleştirdiklerinde tetikleyiciler için dal listesini geçersiz kılmasını istemiyorum. Bunu nasıl yapabilirim?

Koda katkıda bulunma izinleri olan kullanıcılar YAML dosyasını güncelleştirebilir ve ek dalları dahil edebilir/hariç tutabilir. Sonuç olarak, kullanıcılar YAML dosyalarına kendi özellik veya kullanıcı dallarını ekleyebilir ve bu güncelleştirmeyi bir özelliğe veya kullanıcı dalına gönderebilir. Bu, işlem hattının bu daldaki tüm güncelleştirmeler için tetik edilmesine neden olabilir. Bu davranışı önlemek istiyorsanız şunları yapabilirsiniz:

  1. Azure Pipelines kullanıcı arabiriminde işlem hattını düzenleyin.
  2. Tetikleyiciler menüsüne gidin.
  3. Buradan YAML sürekli Tümleştirme tetikleyicisini geçersiz kıl'ı seçin.
  4. Tetikleyici için eklenecek veya hariç tutulacak dalları belirtin.

Bu adımları uyguladığınızda, YAML dosyasında belirtilen tüm CI tetikleyicileri yoksayılır.

YAML işlem hattımda birden çok depom var. Her depo için tetikleyicileri nasıl ayarlarım?

Birden çok depo kullanma başlığı altında, tetikleyicilere bakın.

Teslim alma başarısız oluyor

Kullanıma alma adımı sırasında günlük dosyasında aşağıdaki hatayı görüyorum. Nasıl onarabilirim?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Başarısız olan ödemenizin sorunlarını gidermek için aşağıdaki adımların her birini izleyin:

  • Depo hala var mı? İlk olarak Depolar sayfasında açarak bunu yaptığınızdan emin olun.

  • Depoya bir betik kullanarak mı erişiyorsunuz? Bu durumda İş yetkilendirme kapsamını başvuruda bulunan Azure DevOps depoları ile sınırla ayarını denetleyin. İş yetkilendirme kapsamını başvurulmuş Azure DevOps depoları ile sınırla etkinleştirildiğinde, işlem hattında ilk olarak açıkça başvurulmadıkları sürece bir betik kullanarak Azure Repos Git depolarını kullanıma alamazsınız.

  • İşlem hattının iş yetkilendirme kapsamı nedir?

    • Kapsam koleksiyon ise:

      • Bu aralıklı bir hata olabilir. İşlem hattını yeniden çalıştırın.
      • Birisi Project Collection Derleme Hizmeti hesabına erişimi kaldırmış olabilir.
        • Deponun bulunduğu projenin Proje ayarları'na gidin. Depo depolarına > > özgü depo'yu ve ardından Güvenlik'i seçin.
        • Proje Koleksiyonu Derleme Hizmeti'nin (koleksiyon-adınız) kullanıcı listesinde mevcut olup olmadığını denetleyin.
        • Bu hesabın Etiket oluştur ve Okuma erişimi olup olmadığını denetleyin.

    • Kapsam proje ise:

      • Depo, işlem hattıyla aynı projede mi?
        • Evet:
          • Bu aralıklı bir hata olabilir. İşlem hattını yeniden çalıştırın.
          • Birisi Project Derleme Hizmeti hesabına erişimi kaldırmış olabilir.
            • Deponun bulunduğu projenin Proje ayarları'na gidin. Depo depolarına > > özgü depo'yu ve ardından Güvenlik'i seçin.
            • Proje-adı derleme hizmetinizin (koleksiyon-adınız) kullanıcı listesinde mevcut olup olmadığını denetleyin.
            • Bu hesabın Etiket oluştur ve Okuma erişimi olup olmadığını denetleyin.
        • Hayır:

Yanlış sürüm

İşlem hattında YAML dosyasının yanlış bir sürümü kullanılıyor. Bunun nedeni nedir?

  • CI tetikleyicileri için, göndermekte olduğunuz dalda bulunan YAML dosyası, ci derlemesinin çalıştırılıp çalıştırılmaması gerektiğini görmek için değerlendirilir.
  • Çekme isteği tetikleyicileri için, çekme isteğinin kaynak ve hedef dallarının birleştirilmesinden kaynaklanan YAML dosyası, çekme isteği derlemesinin çalıştırılıp çalıştırılmaması gerektiğini görmek için değerlendirilir.