git veya TFS git depoları Azure Repos oluşturun

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015

Not

Microsoft Team Foundation Server (TFS) 2018 ve önceki sürümlerinde derleme ve yayın işlem hatları tanımlar, çalıştırmalar derlemeler, hizmet bağlantıları hizmet uç noktaları, aşamalar ortamlar ve işler olarak adlandırılan aşamalar olarak adlandırılan bir uygulamadır.

Azure Pipelines, her çekme isteğini otomatik olarak oluşturabilir ve doğrulayabilir ve Azure Repos Git deponuza kaydedebilir.

Derlemek için bir depo seçin

Önce bir depoyu ve ardından bu depodaki bir YAML dosyasını seçerek yeni bir işlem hattı oluşturursunuz. YAML dosyasının bulunduğu depo, depo olarak adlandırılır self . Varsayılan olarak, bu işlem hattının Derlemeleriyle depodur.

Daha sonra, farklı bir depoyu veya birden çok depoyu kullanıma almak için işlem hattınızı yapılandırabilirsiniz. Bunu nasıl yapacağınızı öğrenmek için bkz. Çoklu depo kullanıma alma.

YAML işlem hatları TFS 'de kullanılamaz.

Azure Pipelines derlemelerini tetiklemek ve derlemeler sırasında kodlarını getirmek için havuzlarınıza erişim verilmesi gerekir. Normalde, bir işlem hattının aynı projedeki depolara erişimi vardır. Ancak, farklı bir projedeki depolara erişmek isterseniz, iş erişim belirteçlerineverilen izinleri güncelleştirmeniz gerekir.

CI Tetikleyicileri

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

YAML işlem hatları varsayılan olarak tüm dallarda CI tetikleyicisi ile yapılandırılır.

Dallar

Basit bir söz dizimi ile hangi dalların CI tetikleyicileri alalı olduğunu kontrol etmek için:

trigger:
- master
- releases/*

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

Not

Değişkenler çalışma zamanında değerlendirildik (tetikleyici tetiklendikten sonra) tetikleyicilerde değişkenleri kullanılamaz.

Not

YAML dosyaları oluşturmak için şablonlar kullanıyorsanız, yalnızca işlem hattı için ana YAML dosyasında tetikleyiciler belirtebilirsiniz. Şablon dosyalarında tetikleyicileri belirtemezseniz.

veya kullanan daha karmaşık exclude tetikleyiciler batch için, aşağıdaki örnekte gösterildiği gibi tam söz dizimi kullan gerekir.

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

Yukarıdaki örnekte, bir değişiklik ana dala veya herhangi bir yayın dala itilirse işlem hattı tetiklenir. Ancak, ile başlayan bir sürümler dalda değişiklik yapılırsa old tetiklenir.

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

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

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

Herhangi bir tetikleyici belirtmezseniz, varsayılan değer şunu yazmış gibi olur:

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

Önemli

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

CI çalıştırmalarını toplu işleme

Değişiklikleri sık sık karşıya yüken çok sayıda ekip üyesi varsa, başlatan çalıştırma sayısını azaltmak istiyor olabilir. olarak ayarlanırsa, işlem hattı çalışmaya başladığında sistem çalıştırma tamamlanana kadar bekler ve daha sonra henüz tüm değişikliklerle birlikte başka bir batch true çalıştırma başlatır.

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

Bu örneği netleştirmek için, yukarıdaki işlem hattının A çalışmasına ana işlem hattına yapılan bir itme sonucu olduğunu diyelim. İşlem hattı çalışırken depoya ek B C itmeler ve 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, o zaman noktasına kadar tüm itmeler toplu olarak gruplanır ve yeni bir çalıştırma başlatlanı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 yine de bir terminal durumuna ulaşabilirsiniz. Bu nedenle, bu özelliği birden çok aşama veya onay içeren bir işlem hattında kullanırken dikkatli olmalısınız. Bu gibi durumlarda derlemelerinizi toplu olarak derlemek isterseniz, CI/CD işleminizi biri derleme (toplu işleme ile) ve biri de dağıtımlar için olmak için iki işlem hattına bölmeniz önerilir.

Yollar

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

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

Yolları belirtirken, tetiklenen dalları açıkça belirtmeniz gerekir. Bir işlem hattını yalnızca yol filtresiyle tetikleyeyesiniz; Ayrıca bir dal filtreniz de olması ve yol filtresiyle eşleşen değiştirilen dosyaların da dal filtresiyle eşleşen bir daldan olması gerekir.

İpuçları:

  • Joker karakter, yol filtreleriyle birlikte desteklanmaz.
  • Yollar her zaman deponun köküne göre belirtilir.
  • Yol filtreleri ayarlanmayacaksa, repo kök klasörü varsayılan olarak örtülü olarak dahil edilir.
  • Bir yolu dışlarsanız, daha derin bir klasöre uygun olmadıkça bu yolu ekamazsınız. Örneğin , /tools'ı dışlarsanız /tools/trigger-runs-on-these include
  • Yol filtrelerinin sırası önemli değildir.
  • Git'te yollar büyük/büyük/büyük harfe duyarlıdır. Gerçek klasörlerle aynı durumu kullanmaya emin olun.
  • Değişkenler çalışma zamanında değerlendirildik (tetikleyici tetiklendikten sonra) yollarda değişkenleri kullanılamaz.

Etiketler

Önceki bölümde ele alınan listelerde etiketleri belirtmenin yanı sıra branches , dahil edilecek veya hariç tutulacak etiketleri doğrudan belirtebilirsiniz:

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

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

Önemli

Dal filtreleri ile birlikte Etiketler belirtirseniz, dal filtresi karşılandıysa ya da etiket filtresi karşılandıysa tetikleyici tetiklenir. Örneğin, basılmış bir etiket dal filtresini karşılıyorsa, gönderim dal filtresini karşıladığı için, etiket etiket filtresi tarafından dışlansa bile işlem hattı tetiklenir.

CI'den vazgeçme

CI tetikleyicisini devre dışı bırakma

ci tetikleyicilerini tamamen belirterek devre dışı trigger: none abilirsiniz.

# A pipeline with no CI trigger
trigger: none

Önemli

Bir dala değişiklik İtişletirken, bir CI çalıştırması başlatılanın gerekip gerek olmadığını belirlemek için bu dalda YAML dosyası değerlendirilir.

Daha fazla bilgi için bkz. YAML şemasında tetikleyiciler.

YAML işlem hatları TFS 'de kullanılamaz.

Bireysel işlemeler için CI atlanıyor

ayrıca, bir işlemenin normalde tetikleyeceği bir işlem hattını çalıştırmayı atlayıp Azure Pipelines söyleyebilirsiniz. yalnızca ***NO_CI*** baş yürütmeye ait işlem iletisine dahil edin ve Azure Pipelines cı çalıştırmayı atlar.

ayrıca, bir işlemenin normalde tetikleyeceği bir işlem hattını çalıştırmayı atlayıp Azure Pipelines söyleyebilirsiniz. yalnızca işlem [skip ci] iletisi veya baş yürütmenin açıklamasına dahil edin ve Azure Pipelines cı çalıştırmayı atlar. Aşağıdaki çeşitlerden 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ız içinde farklı adımlar, işler veya aşamalar çalıştırmak yaygın bir senaryodur. Bunu sistem değişkenlerini kullanarak Build.Reason yapabiliriz. Örneğin, aşağıdaki koşulu adımınıza, iş veya aşamanıza ekleyin ve pr doğrulamalarının dışında tut.

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ındır. Örneğin, uygulamanıza belge oluşturmak için bir işlem hattınız ve kaynak kodu derlemek için başka bir işlem hattınız olabilir. Ci tetikleyicilerini bu işlem hatlarının her birsinde uygun dal filtreleri ve yol filtreleri ile yapılandırabilirsiniz. Örneğin, bir işlem hattının klasöre bir güncelleştirmeyi iterek tetiklemesini ve uygulama kodunuza bir güncelleştirme güncelleştirmeyi iterek tetikleyebilirsiniz. docs Bu gibi durumlarda, yeni bir dal oluşturulduğunda işlem hatlarının nasıl tetiklendiğinden anlamalısınız.

Deponıza yeni bir dal (dal filtreleriyle eşleşen) itme davranışı şu şekildedir:

  • İşlem hattınız yol filtrelerine sahipse, yalnızca yeni dalın bu yol filtresiyle eşlenen dosyalarda değişiklikleri varsa tetiklenir.
  • İşlem hattınız yol filtrelerine sahip değilse, yeni dalda değişiklik olsa bile tetiklenir.

Joker karakterler

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

  • Desenini yaML işlem * hattında ile başlatıyorsanız, deseni gibi tırnak içine aldırarak sarmalanız "*-releases" gerekir.
  • Dallar, etiketler ve yollar için, desenin herhangi bir yerinde joker karakter görünebilir.
trigger:
  branches:
    include:
    - master
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR Tetikleyicileri

Çekme isteği (PR) Tetikleyicileri, her bir çekme isteği belirtilen hedef dallarından biriyle açıldığında veya bu tür bir çekme isteğine yapılan değişiklikler gönderildiğinde bir işlem hattının çalışmasına neden olur. Git Azure Repos, bu işlev dal ilkeleri kullanılarak uygulanır. Azure Git Repos çekme isteği doğrulamasını etkinleştirmek için, istenen dala ait 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.

Not

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

Not

Bir dal ilkesi yapılandırsanız bile taslak çekme istekleri bir işlem hattı tetiklemez.

Çatallardan katkıların doğrulanması

Azure Repos çatallardan çekme isteklerinin oluşturulması, aynı depoda veya projede çekme isteklerinin oluşturulmızdan farklı değildir. Çatalları yalnızca projenizin parçası olduğu kuruluş içinde oluşturabilirsiniz.

İş yetkilendirmesi kapsamını sınırla

Azure Pipelines, ardışık düzenlerinizin ç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ına iki Limit işi yetkilendirme kapsamı sağlar:

  • Yayın olmayan işlem hatları için iş yetkilendirmesi kapsamını geçerli proje Ile 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çerlidir.
  • Yayın işlem hatları için iş yetkilendirmesi kapsamını geçerli proje Ile sınırla -Bu ayar yalnızca Klasik yayın işlem hatları için geçerlidir.

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

Azure Repos Git deponuz, işlem hattınıza göre farklı bir projede ise ve işlem hattı türü için iş yetkilendirme kapsamı ayarını sınırla ayarı etkinse, işlem hattınızda ikinci projeye yönelik derleme hizmeti kimliğine izin vermeniz gerekir. Daha fazla bilgi için bkz. Yapı Hizmeti hesabını yönetme izinleri.

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.

  • İş yetkilendirmesi 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çerlidir.

geçerli proje için iş yetkilendirme kapsamını sınırla özelliği etkinleştirilmediği takdirde, koleksiyon kapsamlı erişim belirteçleri ile çalıştırın Pipelines. Bu ayar, geçerli projeye tüm işlem hatları için erişim kapsamını azaltmanıza olanak sağlar. bu, kuruluşunuzdaki farklı bir projede Azure Repos Git deposuna erişiyorsanız işlem hattınızı etkileyebilir.

Azure Repos Git deponuz, işlem hattınıza göre farklı bir projede ise ve iş yetkilendirmesi kapsamını sınırla ayarı etkinse, ardışık düzenin derleme hizmeti kimliğine ikinci projeye izin vermeniz gerekir. Daha fazla bilgi için bkz. iş yetkilendirme kapsamı.

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

iş yetkilendirmesi kapsamını başvurulan Azure DevOps depolarıyla sınırla

Pipelines, izin verilen Azure DevOps depolarına yönelik sınırla iş yetkilendirme kapsamı etkin olmadığı sürece, geçerli proje için önceki sınır iş yetkilendirme kapsamı bölümünde açıklandığı gibi, yetkili projelerdeki tüm Azure DevOps depolara erişebilir. bu seçenek etkinken, tüm işlem hatları için erişim kapsamını yalnızca checkout uses bu depoyu kullanan işlem hattı işinde bir adım veya bir bildirime göre açıkça başvuruda bulunulan depoların Azure DevOps azaltabilirsiniz.

bu ayarı yapılandırmak için Pipelines, kuruluş ayarları veya Project ayarları Ayarlar gidin. Kuruluş düzeyinde etkinleştirilirse, ayar gri renkte görünür ve proje ayarları düzeyinde kullanılamaz.

Önemli

iş yetkilendirme kapsamını başvurulan Azure DevOps sınırla , yeni kuruluşlar ve proje 2020 ' den sonra oluşturulan projeler için varsayılan olarak etkinleştirilir.

iş yetkilendirme kapsamını başvurulan Azure DevOps depolarıyla sınırlandırdığınızda , yaml işlem hatlarınız, depoyu kullanan işte bir kullanıma alma adımı olarak işlem hattında kullanmak istediğiniz tüm Azure Repos Git depolarınıza açıkça başvurmalıdır. depoya ilk olarak başvurulmuyorsa, bir Azure Repos git deposu için betik görevleri ve git komutlarını kullanarak kod getirimeyeceksiniz.

iş yetkilendirmesi kapsamını başvurulan Azure DevOps depolarla sınırlandırdığınızda , işlem hattınızda kullanmadan önce Azure Repos Git deposuna açıkça başvurulmanız gereken birkaç özel durum vardır.

  • İşlem hattınızda açık bir kullanıma alma adımlarınız yoksa, bir checkout: self adımınız olur ve self Depo kullanıma alındı.
  • Ortak projedeki bir depoda salt okuma işlemleri gerçekleştirmek için bir komut dosyası kullanıyorsanız, bir adımda ortak proje deposuna başvurmanız gerekmez checkout .
  • Bir PAT gibi kendi kimlik doğrulamasını sağlayan bir komut dosyası kullanıyorsanız, bu depoya bir adımla başvurmanız gerekmez checkout .

örneğin, iş yetkilendirme kapsamını başvurulan Azure DevOps depolarla sınırla , işlem hatlarınız kuruluşunuzdaki depoda ise ve depoyu kullanıma almak FabrikamProject/Fabrikam için bir komut dosyası kullanmak istiyorsanız, FabrikamProject/FabrikamTools bu depoya bir checkout adımla veya bir ifadesiyle başvurulmalısınız uses .

FabrikamToolsBir kullanıma alma adımı kullanarak depoyu işlem hattınızda zaten kullanıma sunmadıysanız, daha sonra bu depoyla etkileşim kurmak 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 senaryo için, çok depolü kullanıma alma, işlem hattınızdaki ek depoları kullanıma almak üzere betikleri kullanma gereksinimini ortadan kaldırarak yararlanılabilir olabilir. Daha fazla bilgi için bkz. işlem hattınızda birden çok depo kullanıma alma.

Kullanıma alma

bir işlem hattı tetiklendiğinde, Azure Pipelines Azure Repos Git deposundan kaynak kodunuzu çeker. Bunun nasıl gerçekleştemelerinin çeşitli yönlerini kontrol edebilirsiniz.

Git 'in tercih edilen sürümü

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

Kullanıma alma yolu

Tek bir depoyu kullanıma sundıysanız, varsayılan olarak, kaynak kodunuz adlı bir dizinde kullanıma sunulacaktır s . YAML işlem hatları için ile belirterek bunu değiştirebilirsiniz checkout path . Belirtilen yol göreli $(Agent.BuildDirectory) . Örneğin: kullanıma alma yolu değeri mycustompath ve ise $(Agent.BuildDirectory) C:\agent\_work\1 , kaynak kodu kullanıma alınacaktır C:\agent\_work\1\mycustompath .

Birden çok checkout adım kullanıyorsanız ve bu klasörü kullanarak açıkça belirtmezseniz, path her bir depo, depodan sonra adlı öğesinin bir alt klasörüne yerleştirilir s . Örneğin, ve adlı iki depoya göz atın tools code , kaynak kodu ve ' de kullanıma sunulacaktır C:\agent\_work\1\s\tools C:\agent\_work\1\s\code .

Lütfen, kullanıma alma yolu değerinin yukarıdaki herhangi bir dizin düzeyini oluşturacak şekilde ayarlanmadığını, bu $(Agent.BuildDirectory) nedenle path\..\anotherpath geçerli bir kullanıma alma yolu (yani) ile sonuçlanabileceğini unutmayın C:\agent\_work\1\anotherpath , ancak gibi bir değer ..\invalidpath (örn.) olur C:\agent\_work\invalidpath .

İşlem path hattınızdaki kullanıma alma adımında ayarı yapılandırabilirsiniz.

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ülleri

submodules Alt modüllerdendosyaları indirmek isterseniz, Işlem hattınızdaki kullanıma alma adımında ayarı yapılandırabilirsiniz.

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

Yapı işlem hattı, git alt modüllerinizi oldukları sürece kullanıma alacak:

  • Kimliği doğrulanmamış: Kopyalamak veya getirmek için kimlik bilgileri olmadan ortak, kimliği doğrulanmamış bir depo.

  • Denetiminden

    • yukarıda belirtilen Azure Repos Git deposu ile aynı projede yer alır. Ana depodan kaynakları almak için aracı tarafından kullanılan kimlik bilgileri, alt modüller için kaynakları almak için de kullanılır.

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

      • Bu bir tane kullanıma alınmış olacaktır: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        bu örnekte, alt modül aynı Azure DevOps kuruluştaki bir depoya (FabrikamFiber), ancak farklı bir projede (FabrikamFiberProject) başvurur. Ana depodan kaynakları almak için aracı tarafından kullanılan kimlik bilgileri, alt modüller için kaynakları almak için de kullanılır. Bu, iş erişim belirtecinin ikinci projedeki depoya erişimine sahip olmasını gerektirir. Yukarıdaki bölümde açıklandığı gibi iş erişim belirtecini kısıtladıysanız bunu yapamazsınız. İş erişim belirtecinin ikinci projedeki depoya, (a) ikinci projedeki proje yapı hizmeti hesabına açıkça erişim vererek veya (b) tüm kuruluşun proje kapsamlı belirteçleri yerine koleksiyon kapsamlı erişim belirteçleri kullanarak erişmesine izin verebilirsiniz. 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 bir tanesi kullanıma alınmamış: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alt modülleri kullanıma alma seçeneğinin kullanımına alternatif

Bazı durumlarda, alt modülleri kullanıma al seçeneğini kullanamazsınız. Alt modüllere erişmek için farklı bir kimlik bilgileri kümesinin gerekli olduğu bir senaryoya sahip olabilirsiniz. bu durum, örneğin, ana depo ve alt modül depolarınız aynı Azure DevOps kuruluşta depolanmıyorsa veya iş erişim belirtecinizin farklı bir projedeki depoya erişimi yoksa oluşabilir.

Alt modülleri kullanıma alma seçeneğini kullanamıyoruz, bunun yerine alt modüller getirmek için özel bir betik adımı kullanabilirsiniz. İlk olarak, bir kişisel erişim belirteci (PAT) alın ve bunu ile önek yapın pat: . Sonra, Base64- bu önekli dizeyi temel bir kimlik doğrulama belirteci oluşturacak şekilde kodlayın. Son olarak, bu betiği ardışık düzene ekleyin:

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

"<BASE64_ENCODED_STRING>" öğesini Base64 kodlamalı "Pat: token" dizeniz ile değiştirdiğinizden emin olun.

Projenizde bir gizli dizi değişkeni kullanın veya oluşturduğunuz temel kimlik doğrulama belirtecini depolamak için işlem hattı oluşturun. Yukarıdaki git komutunda gizli anahtarı doldurmak için bu değişkeni kullanın.

Not

S: bir git kimlik bilgileri yöneticisini aracıda neden kullanamıyorum? Y : Alt modül kimlik bilgilerini özel derleme aracısında yüklü olan bir git kimlik bilgileri Yöneticisi 'nde depolamak, genellikle kimlik bilgileri Yöneticisi her güncelleştirildiğinde kimlik bilgilerini yeniden girmeniz istenebilir. Bu, Kullanıcı etkileşimi mümkün olmadığında otomatik derlemeler sırasında istenmez.

Yüzeysel getirme

Geçmişin ne kadar geri yükleneceğini sınırlamak isteyebilirsiniz. Bu durum etkili bir şekilde sonuçlanır git fetch --depth=n . Deponuz büyükse, bu seçenek derleme işlem hattınızı daha verimli hale getirir. Deponuz uzun bir süre kullanımda ve boyutlandırılabilir geçmişle kullanılıyorsa büyük olabilir. Büyük dosyaları eklediyseniz ve daha sonra sildiyseniz de büyük olabilir.

İşlem fetchDepth hattınızdaki kullanıma alma adımında ayarı yapılandırabilirsiniz.

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

Bu durumlarda bu seçenek, ağ ve depolama kaynaklarını korumanıza yardımcı olabilir. Ayrıca zamandan tasarruf edebilir. Her zaman zaman kaydetmediği sebebi, bazı durumlarda sunucunun belirttiğiniz derinliğe karşı indirileceği bir işleme süresini hesaplamak için ihtiyaç duyduğu bir nedendir.

Not

İşlem hattı başlatıldığında, derleme dalı bir işleme KIMLIĞI olarak çözümlenir. Ardından, aracı dalı getirir ve istenen yürütmeyi denetler. Bir dalın bir kayıt KIMLIĞINE çözümlenme ve aracının kullanıma alma işlemi gerçekleştirdiği zaman arasında küçük bir pencere vardır. Dal hızlı bir şekilde güncelliyor ve basit getirme için çok küçük bir değer ayarlarsanız, aracı kullanıma almayı denediğinde kayıt olmayabilir. Bu durumda, yüzeysel getirme derinliği ayarını artırın.

Kaynakları eşitleme

Yeni işlemeler getirmeyi atlamak isteyebilirsiniz. Bu seçenek, aşağıdakileri yapmak istediğiniz durumlarda yararlı olabilir:

  • Kendi özel seçeneklerinizi kullanarak git init, config ve Fetch.

  • Sürüm denetimindeki koda bağlı olmayan Otomasyonu (örneğin bazı betikler) çalıştırmak için bir yapı işlem hattı kullanın.

İşlem hattınızdaki kullanıma alma adımında kaynak eşitleme ayarını ayarlayarak yapılandırabilirsiniz checkout: none .

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

Not

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

Derlemeyi temizle

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

Genel olarak, kendi içinde barındırılan aracılarınızı daha hızlı performans için, repo temizlemeyin. Bu durumda, en iyi performansı elde etmek için, derlemek için kullanmakta olduğu görev veya aracın herhangi bir Temiz seçeneğini devre dışı bırakarak artımlı olarak da derlemeye devam edin.

Bir önceki derlemede yer alan artık dosyaların neden olduğu sorunları önlemek için)po temizlemeniz gerekirse seçenekleriniz aşağıda verilmiştir.

Not

Her seferinde yeni bir aracı alacağınız için, Microsoft tarafından barındırılan bir aracı kullanıyorsanız Temizleme işlemi etkili değildir.

İşlem clean hattınızdaki kullanıma alma adımında ayarı yapılandırabilirsiniz.

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 true Derleme ardışık düzenine ayarlandığında, içindeki tüm değişiklikleri geri alır $(Build.SourcesDirectory) . Daha belirgin olarak, kaynağı getirmeden önce aşağıdaki git komutları yürütülür.

git clean -ffdx
git reset --hard HEAD

Daha fazla seçenek için workspace bir ayarını yapılandırabilirsiniz.

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.

  • çıktılar: önceki kullanıma alma görevinde açıklanan Temizleme ayarıyla aynı işlem ve ayrıca: siler ve yeniden oluşturur $(Build.BinariesDirectory) . $(Build.ArtifactStagingDirectory)Ve ' nin her $(Common.TestResultsDirectory) zaman ve her derlemeden önce bu ayarlardan bağımsız olarak silindiğini ve yeniden oluşturulduğunu unutmayın.

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

  • Tümü: 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ı

Takımınıza, tamamlanan derlemede her dosyanın hangi sürümünün dahil olduğunu kolayca tanımlaması için kaynak kod dosyalarınızı etiketlemek istiyor olabilirsiniz. Ayrıca kaynak kodun tüm derlemeler için mi yoksa yalnızca başarılı derlemeler için mi etiketlenmiş olacağını belirtme seçeneğiniz de vardır.

Şu anda bu ayarı YAML'de yapılandıramazsanız, 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 (YAML) yapılandırma.

Klasik düzenleyiciden YAML'yi seçin, Kaynakları al görevini seçin ve ardından istenen özellikleri orada yapılandırabilirsiniz.

Klasik düzenleyiciden YAML'yi ve Kaynakları > seçin.

Etiket biçiminde" kapsamı "All" olan kullanıcı tanımlı ve önceden tanımlanmış değişkenleri kullanabilirsiniz. Örneğin:

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

İlk dört değişken önceden tanımlanmıştır. My.Variable, değişkenler sekmesinde sizin tarafından tanımlanabilir.

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

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

Kaynaklar derleme işlem hattınız tarafından etiketlendikten sonra, tamamlanmış derlemeye otomatik olarak Git refs/tags/{tag} ref'e sahip bir yapıt eklenir. Bu, takımınıza ek izlenebilirlik ve derlemeden, yerleşik koda gitmek için daha kolay bir yol sağlar. Etiket, derleme tarafından üretilen bir yapıt olarak kabul edilir. Derleme el ile veya bir saklama ilkesi aracılığıyla silindiğinde, etiket de silinir.

SSS

Azure Repos tümleştirmeyle ilgili sorunlar üç kategoride yer almalıdır:

Başarısız Tetikleyiciler

Yalnızca CI/PR tetikleyicilerine sahip yeni bir YAML işlem hattı oluşturdum, ancak işlem hattı tetiklenmiyor.

Başarısız tetikleyicilerinizdeki sorunları gidermek için bu adımların her birini izleyin:

  • YAML dosyasında ya da depo için dal ilkelerinde PR tetikleyicisini mi yapılandırıyorsunuz? Azure Repos Git deposu için, yaml dosyasında bir PR tetikleyicisi yapılandıramazsınız. Dal ilkelerinikullanmanız gerekir.
  • Ardışık düzen duraklatıldı veya devre dışı mı? işlem hattının düzenleyicisini açın ve ardından denetlemek için Ayarlar ' yi seçin. İşlem hattınız duraklatılmışsa veya devre dışıysa, Tetikleyiciler çalışmaz.

  • YAML dosyasını doğru dalda güncelleştirmiş musunuz? Bir dala güncelleştirme göndermeniz durumunda, aynı dalda bulunan YAML dosyası CI davranışını yönetir. Bir güncelleştirmeyi kaynak dalına dağıtırsanız, YAML dosyası kaynak dalı hedef dalı ile birleştirme işlemi, ç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 şekilde yapılandırdınız mı? Bir YAML tetikleyicisi tanımladığınızda, dallar, Etiketler ve yollar için hem dahil etme hem de dışlama yan tümceleri belirtebilirsiniz. Include yan tümcesinin işlemenizden ayrıntılarla eşleştiğinden ve exclude yan tümcesinin bunları dışiçermediğinden emin olun. Tetikleyicilerin sözdizimini denetleyin ve doğru olduğundan emin olun.

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

  • YAML dosyanız için şablonlar mı kullanıyorsunuz? Varsa, tetikleyiclerinizin Main YAML dosyasında tanımlandığından emin olun. Şablon dosyaları içinde tanımlanan Tetikleyiciler desteklenmez.

  • Değişikliklerinizi gönderdiğiniz dalları veya yolları dışlıyorsunuz musunuz? Dahil edilen bir dalda bir değişikliği dahil eden yola göndererek test edin. Tetiklerde bulunan yolların büyük/küçük harfe duyarlı olduğunu unutmayın. Tetikleyicilere yollar belirtirken gerçek klasörlerle aynı durumu kullandığınızdan emin olun.

  • Yol filtrelerinde Joker karakterlere sahipsiniz musunuz? Bu makalede açıklandığı gibi yollarındaki Joker karakterlere ilişkin sınırlamaları anlayın.

  • Yeni bir dal göndermi? Öyleyse, yeni dal yeni bir çalıştırma başlatılamayabilir. "Yeni dallar oluşturulduğunda tetikleyicilerinin davranışı" bölümüne bakın.

CI veya PR Tetikleyicileri sorunsuz şekilde çalışıyor. Ancak, şimdi çalışmayı durdurmuştur.

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

  • Çekme ortamınızda birleştirme çakışmalarıyla mı sahipsiniz? İşlem hattını tetiklemeyen bir çekme isteği için onu açın ve bir birleştirme çakışması olup olmadığını kontrol edin. Birleştirme çakışmasını çözün.

  • İtme veya çekme isteği olaylarının işlenmesinde bir gecikme mi yaşıyor musunuz? Bunu genellikle sorunun tek bir işlem hattına özgü olup olmadığını görebilir veya projenizdeki tüm işlem hatları veya depolarda ortak olduğunu görürsünüz. Depolardan herhangi birine yönelik bir gönderim veya bir PR Güncelleştirmesi bu belirtiyle karşılaşıyorsa, güncelleştirme olaylarını işlerken gecikmeler yaşanıyor olabilir. Durum sayfamızdabir hizmet kesintisi yaşanık olup olmadığını denetleyin. Durum sayfasında bir sorun varsa takımımız üzerinde çalışmaya başlamış olması gerekir. Sorun hakkındaki güncelleştirmeler için sayfayı sık sık denetleyin.

Kullanıcıların YAML dosyasını güncelleştirdiklerinde tetikleyicilerle ilgili dalların listesini geçersiz kılmasını istemiyorum. Bunu nasıl yapabilirim?

Kod ekleme izinlerine sahip kullanıcılar YAML dosyasını güncelleştirebilir ve ek dalları dahil edebilir/hariç tutabilir. Sonuç olarak, kullanıcılar kendi özelliklerini veya Kullanıcı dalını YAML dosyasına ekleyebilir ve bu güncelleştirmeyi bir özellik veya Kullanıcı dalına gönderebilir. Bu, söz konusu daldaki tüm güncelleştirmeler için işlem hattının tetiklenmesi oluşmasına neden olabilir. Bu davranışı engellemek istiyorsanız şunları yapabilirsiniz:

  1. Azure Pipelines Kullanıcı arabirimindeki işlem hattını düzenleyin.
  2. Tetikleyiciler menüsüne gidin.
  3. YAML sürekli tümleştirme tetikleyicisini buradan geçersiz kıl' ı seçin.
  4. Tetikleyici için dahil edilecek veya hariç tutulacak dalları belirtin.

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

YAML ardışık düzeninde birden çok depom var. Her depoya yönelik Tetikleyiciler ayarlamak Nasıl yaparım??

Bkz. birden çok depo kullanmaiçindeki Tetikleyiciler.

Kullanıma alma başarısız

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

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 tetikleyicilerinizdeki sorunları gidermek için bu adımların her birini izleyin:

  • Depo hala var mı? ilk olarak, Repos sayfasında açarak olduğundan emin olun.

  • Bir komut dosyası kullanarak depoya mi erişiyorsunuz? öyleyse, iş yetkilendirmesi kapsamını başvurulan Azure DevOps depoları ile sınırla ayarını kontrol edin. iş yetkilendirme kapsamını başvurulan Azure DevOps depolarıyla sınırlandırdığınızda , işlem hattında açıkça başvurulmadığı takdirde bir komut dosyası kullanarak Azure Repos Git depolarını kullanıma açamazsınız.

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

    • Kapsam koleksiyon ise:

      • Bu işlem aralıklı bir hata olabilir. İşlem hattını yeniden çalıştırın.
      • birisi Project koleksiyonu derleme hizmeti hesabına erişimi kaldırmış olabilir.
        • Deponun bulunduğu projenin proje ayarlarına gidin. belirli bir depoyu > Repos > depoları seçin.
        • Project koleksiyonu derleme hizmeti 'nin (koleksiyon adı) kullanıcı listesinde bulunup bulunmadığını denetleyin.
        • Bu hesabın etiket oluşturma ve okuma erişimi olup olmadığını denetleyin.
    • Kapsam Proje ise:

      • Ardışık düzen ile aynı projede depo mi?
        • Yes
          • Bu işlem 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. belirli bir depoyu > Repos > depoları seçin.
            • -Proje adı derleme hizmetinizin (koleksiyon adı) Kullanıcı listesinde olup olmadığını denetleyin.
            • Bu hesabın etiket oluşturma ve okuma erişimi olup olmadığını denetleyin.
        • Hayır:
          • İşlem hatlarınız ortak bir projede mi?
            • Evet: genel projenizin dışındaki kaynaklara erişemezsiniz. Projeyi özel yapın.
            • Hayır: erişim sağlamak için ek adımlar gerçekleştirmeniz gerekir. İşlem hattınızı proje A 'da olduğunu ve deponuzun B projesi içinde olduğunu söylememizi söyleyin.
              • Deponun bulunduğu projenin proje ayarlarına gidin (B). belirli bir depoyu > Repos > depoları seçin.
              • -Proje-adı Yapı hizmetinizi (koleksiyon adı) Kullanıcı listesine ekleyin; burada-proje adınız, ardışık düzenin bulunduğu projenin adıdır (A).
              • Hesap için oluşturma etiketi ve okuma erişimi verin.

Yanlış sürüm

Ardışık düzende YAML dosyasının yanlış bir sürümü kullanılıyor. Bunun nedeni nedir?

  • CI Tetikleyicileri için, dağıttığınız dalda olan YAML dosyası bir CI derlemesinin çalıştırılması gerekip gerekmediğini görmek için değerlendirilir.
  • PR Tetikleyicileri için, çekme isteğinin kaynak ve hedef dallarının birleştirilmesinden kaynaklanan YAML dosyası, bir PR derlemesinin çalıştırılması gerekip gerekmediğini görmek için değerlendirilir.