Git Azure Repos TFS Git depoları oluşturma

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***

Ç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
• iş yetkilendirmesi kapsamını başvurulan Azure DevOps depolarıyla sınırla

İş 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ırlahakkı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 checkoutuses 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.

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

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

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

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.

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.

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.

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.

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

Derlemeyi temizle

Bir yapı çalıştırılmadan önce şirket içinde barındırılan aracının çalışma dizinini temizlemek için farklı biçimler gerçekleştirebilirsiniz.

Genel olarak, şirket içinde barındırılan aracılarınız için daha hızlı performans için depoyu temizlemeyin. Bu durumda, en iyi performansı elde etmek için, oluşturmak için kullandığınız görev ya da aracın tüm Temizleme seçeneklerini devre dışı bırakarak artımlı olarak da oluşturulduğunuzdan emin olun.

Depoyu temizlemeniz gerekiyorsa (örneğin, önceki bir derlemeden kalan dosyalardan kaynaklanan sorunlardan kaçınmak için) seçenekleriniz aşağıda verilmiştir.

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

git clean -ffdx
git reset --hard HEAD

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

Kaynakları etiketle

Takımınızın her bir dosyanın hangi sürümünün tamamlanmış yapıda ekleneceğini kolayca belirlemesini sağlamak için kaynak kodu dosyalarınızı etiketlemek isteyebilirsiniz. Kaynak kodun tüm derlemeler için mi yoksa yalnızca başarılı derlemeler için mi etiketlenmesi gerektiğini de belirtebilirsiniz.

Etiket biçiminde , Kullanıcı tanımlı ve "tümü" kapsamına sahip ö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 , My.Variablesizin tarafınızdan tanımlanabilir.

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

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

Kaynaklar derleme işlem hattınızla etiketlendikten sonra, tamamlanan yapıya git başvurusu olan bir yapıt refs/tags/{tag} otomatik olarak eklenir. Bu, takımınızdan ek izlenebilirlik sağlar ve derlemeden derlenmiş koda gezinmek için daha kolay bir yol sağlar. Etiket, yapı tarafından üretildiğinden, derleme yapıtı olarak değerlendirilir. Yapı el ile veya bir bekletme ilkesi üzerinden silindiğinde, etiket de silinir.