GitHub depoları oluşturma

Azure DevOps Services

Azure Pipelines her çekme isteğini otomatik olarak derleyip doğrulayabilir ve GitHub deponuza işleyebilir. Bu makalede GitHub ile Azure Pipelines arasındaki tümleştirmenin nasıl yapılandırıldığı açıklanır.

GitHub ile işlem hatları tümleştirmesi konusunda yeniyseniz, İlk işlem hattınızı oluşturmaadımlarını izleyin. GitHub ile Azure Pipelines arasındaki tümleştirmeyi yapılandırma ve özelleştirme hakkında daha fazla bilgi edinmek için bu makaleye geri dönün.

Kuruluşlar ve kullanıcılar

GitHub ve Azure Pipelines, birlikte iyi bir şekilde tümleşen iki bağımsız hizmettir. Her birinin kendi kuruluşu ve kullanıcı yönetimi vardır. Bu bölümde, kuruluşun ve kullanıcıların GitHub'dan Azure Pipelines'a nasıl çoğaltılması konusunda bir öneride bulunabilirsiniz.

Kuruluş

GitHub'ın yapısı,depoları içeren kuruluşlarından ve kullanıcı hesaplarından oluşur. GitHub'ınbelgelerine bakın.

GitHub kuruluş yapısı

Azure DevOps'un yapısı,projeleri içeren kuruluşlardan oluşur. Bkz. Kuruluş yapınızı planlama.

Azure DevOps kuruluş yapısı

Azure DevOps, GitHub yapınızı aşağıdakilerle yansıtabilir:

• GitHub kuruluşunuz veya kullanıcı hesabınız için DevOps kuruluşu
• GitHub depolarınız için DevOps Projeleri

Azure DevOps ile eşlenen GitHub yapısı

Azure DevOps'ta aynı yapıyı ayarlamak için:

1. GitHub kuruluşunuzun veya kullanıcı hesabınızın adını taşıyan bir DevOps kuruluşu oluşturun. https://dev.azure.com/your-organizationgibi bir URL'si olacaktır.
2. DevOps kuruluşunda depolarınızın adını taşıyan projeler oluşturun. https://dev.azure.com/your-organization/your-repositorygibi URL'leri olacaktır.
3. DevOps Projesi'nde GitHub kuruluşundan ve oluşturdukları depodan (your-organization.your-repositorygibi) adlı işlem hatları oluşturun. O zaman, hangi depolar için oldukları açıktır.

Bu düzenin ardından GitHub depolarınız ve Azure DevOps Projeleriniz eşleşen URL yollarına sahip olur. Mesela:

Hizmet	URL
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Kullanıcı

GitHub kullanıcılarınız Azure Pipelines'a otomatik olarak erişemez. Azure Pipelines, GitHub kimliklerinin farkında değildir. Bu nedenle, Azure Pipelines'ı GitHub kimliklerini ve e-posta adreslerini kullanarak kullanıcılara bir derleme hatası veya çekme isteği doğrulama hatası hakkında otomatik olarak bildirim gönderecek şekilde yapılandırmanın bir yolu yoktur. GitHub kullanıcılarını çoğaltmak için Azure Pipelines'da açıkça yeni kullanıcılar oluşturmanız gerekir. Yeni kullanıcılar oluşturduktan sonra Azure DevOps'ta izinlerini GitHub'daki izinlerini yansıtacak şekilde yapılandırabilirsiniz. DevOps kimliklerini kullanarak DevOps'ta bildirimleri de yapılandırabilirsiniz.

GitHub kuruluş rolleri

GitHub kuruluş üyesi rolleri https://github.com/orgs/your-organization/people bulunur (your-organizationdeğiştirin).

DevOps kuruluş üyesi izinleri https://dev.azure.com/your-organization/_settings/security (your-organizationdeğiştir) konumunda bulunur.

GitHub kuruluşundaki roller ve Azure DevOps kuruluşundaki eşdeğer roller aşağıda gösterilmiştir.

GitHub kuruluş rolü	DevOps kuruluş eşdeğeri
Sahip	Project Collection Administrators üyesi
Faturalama yöneticisi	Project Collection Administrators üyesi
Üye	Project Collection Valid Usersüyesi. Varsayılan olarak, Üye grubunun yeni proje oluşturma izni yoktur. İzni değiştirmek için, grubun Create new projects iznini Allowolarak ayarlayın veya ihtiyacınız olan izinlere sahip yeni bir grup oluşturun.

GitHub kullanıcı hesabı rolleri

GitHub kullanıcı hesabının bir rolü vardır ve bu da hesabın sahipliğidir.

DevOps kuruluş üyesi izinleri https://dev.azure.com/your-organization/_settings/security (your-organizationdeğiştir) konumunda bulunur.

GitHub kullanıcı hesabı rolü aşağıdaki gibi DevOps kuruluş izinleriyle eşlenir.

GitHub kullanıcı hesabı rolü	DevOps kuruluş eşdeğeri
Sahip	Project Collection Administrators üyesi

GitHub deposu izinleri

GitHub deposu izinleri https://github.com/your-organization/your-repository/settings/collaboration (your-organization ve your-repositorydeğerini değiştirin) konumunda bulunur.

DevOps proje izinleri https://dev.azure.com/your-organization/your-project/_settings/security bulunur (your-organization ve your-projectdeğerini değiştirin).

GitHub depoları ile Azure DevOps Projeleri arasındaki eşdeğer izinler aşağıdaki gibidir.

GitHub deposu izni	DevOps projesi eşdeğeri
Admin	Project Administrators üyesi
Yazmak	Contributors üyesi
Okumak	Readers üyesi

GitHub deponuz ekiplere izin verirse, Azure DevOps proje ayarlarınızın Teams bölümünde eşleşen ekipler oluşturabilirsiniz. Ardından, ekipleri kullanıcılar gibi yukarıdaki güvenlik gruplarına ekleyin.

İşlem hattına özgü izinler

DevOps projesindeki belirli işlem hatları için kullanıcılara veya ekiplere izin vermek için şu adımları izleyin:

1. Projenin İşlem Hatları sayfasını ziyaret edin (örneğin, https://dev.azure.com/your-organization/your-project/_build).
2. Belirli izinlerin ayarlanacağı işlem hattını seçin.
3. '...' bağlam menüsünden güvenlikseçin.
4. Ekle'yi seçin... Belirli bir kullanıcı, ekip veya grup eklemek ve işlem hattı izinlerini özelleştirmek için.

GitHub depolarına erişim

YAML

Önce bir GitHub deposu ve ardından bu depoda bir YAML dosyası seçerek yeni bir işlem hattı oluşturursunuz. YAML dosyasının bulunduğu depo self deposu olarak adlandırılır. 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.

Önce depo türü için GitHub ve ardından erişiminiz olan depolardan birini seçerek yeni bir işlem hattı oluşturursunuz.

Derlemelerini tetikleyebilmek ve derlemeler sırasında kodlarını getirmek için Azure Pipelines'a depolarınıza erişim verilmelidir.

İşlem hattı oluştururken GitHub depolarınıza Azure Pipelines erişimi vermek için üç kimlik doğrulama türü vardır.

Kimlik doğrulama türü	İşlem hatları kullanılarak çalıştırılır	GitHub Denetimleri ile çalışır
1. GitHub App	Azure Pipelines kimliği	Evet
2. OAuth	Kişisel GitHub kimliğiniz	Hayır
3. Kişisel erişim belirteci (PAT)	Kişisel GitHub kimliğiniz	Hayır

GitHub uygulama kimlik doğrulaması

Azure Pipelines GitHub Uygulaması, sürekli tümleştirme işlem hatları için önerilen kimlik doğrulama türüdür. GitHub Uygulamasını GitHub hesabınıza veya kuruluşunuza yükledikten sonra işlem hattınız kişisel GitHub kimliğinizi kullanmadan çalışır. Derlemeler ve GitHub durum güncelleştirmeleri Azure Pipelines kimliği kullanılarak gerçekleştirilir. Uygulama, GitHub'da derleme, test ve kod kapsamı sonuçlarını görüntülemek için GitHub Denetimleri ile çalışır.

GitHub Uygulamasını kullanmak için, bu uygulamayı GitHub kuruluşunuza veya bazı veya tüm depolar için kullanıcı hesabınıza yükleyin. GitHub Uygulaması uygulamanın giriş sayfasındanyüklenebilir ve kaldırılabilir.

Yüklemeden sonra GitHub Uygulaması, depolar için işlem hatları oluşturulduğunda Azure Pipelines'ın GitHub'da (OAuth yerine) varsayılan kimlik doğrulama yöntemi haline gelir.

GitHub kuruluşundaki tüm depolar için GitHub Uygulamasını yüklerseniz Azure Pipelines'ın toplu e-posta göndermesi veya sizin adınıza işlem hatlarını otomatik olarak ayarlaması konusunda endişelenmeniz gerekmez. Ancak, uygulama tüm depolar için yüklüyse, uygulama tarafından kullanılan belirteç özel depolar da dahil olmak üzere tüm depolara erişebilir. Güvenlik nedeniyle özel ve genel depoların kuruluş düzeyinde ayrılması önerilir. Bu, yalnızca özel depoları olmayan genel projeler için ayrılmış bir kuruluşa sahip olmak anlamına gelir. Bazı nedenlerden dolayı, tüm depolar için erişim kullanmak yerine aynı kuruluşta genel ve özel depoların olması gerekiyorsa, uygulamanın erişmesi gereken depoları açıkça seçin. Bu, yöneticiler için daha fazla çalışma gerektirir ancak daha iyi güvenlik yönetimi sağlar.

GitHub'da gereken izinler

Azure Pipelines GitHub uygulamasının yüklenmesi için GitHub kuruluş sahibi veya depo yöneticisi olmanız gerekir. Ayrıca, sürekli tümleştirme ve çekme isteği tetikleyicileri içeren bir GitHub deposu için işlem hattı oluşturmak için gerekli GitHub izinlerinin yapılandırılmış olması gerekir. Aksi takdirde, işlem hattı oluşturulurken depo listesinde görünmez. Deponun kimlik doğrulama türüne ve sahipliğine bağlı olarak uygun erişimin yapılandırıldığından emin olun.

• Depo kişisel GitHub hesabınızdaysa, Azure Pipelines GitHub Uygulamasını kişisel GitHub hesabınıza yüklediğinizde Azure Pipelines'da işlem hattını oluştururken bu depoyu listeleyebilirsiniz.

• Depo başka birinin kişisel GitHub hesabındaysa, diğer kişinin kişisel GitHub hesabına Azure Pipelines GitHub Uygulamasını yüklemesi gerekir. Deponun ayarlarına "ortak çalışanlar" altında ortak çalışan olarak eklenmelisiniz. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin. Bunu yaptıktan sonra, bu depo için bir işlem hattı oluşturabilirsiniz.

• Depo sahibi olduğunuz bir GitHub kuruluşundaysa GitHub kuruluşuna Azure Pipelines GitHub Uygulamasını yükleyin. Ayrıca, deponun ayarlarına "ortak çalışanlar ve ekipler" altında bir ortak çalışan olarak veya ekibinizin eklenmesi gerekir.

• Depo başka birinin sahip olduğu bir GitHub kuruluşundaysa, GitHub kuruluş sahibi veya depo yöneticisi kuruluşa Azure Pipelines GitHub Uygulamasını yüklemelidir. Deponun ayarlarına "ortak çalışanlar ve ekipler" bölümünden ortak çalışan olarak eklenmelidir veya ekibiniz eklenmelidir. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin.

GitHub Uygulama izinleri

GitHub Uygulaması yükleme sırasında aşağıdaki izinleri istemektedir:

İzin	Azure Pipelines izni nasıl kullanır?
Koda yazma erişimi	Yalnızca kasıtlı eyleminiz üzerine Azure Pipelines, GitHub deponuzun seçili bir dalı için bir YAML dosyası işleyerek işlem hattı oluşturmayı basitleştirir.
Meta verilere okuma erişimi	Azure Pipelines, derlemenin özetinde bir derlemeyle ilişkili depoyu, dalları ve sorunları görüntülemek için GitHub meta verilerini alır.
Denetimlere okuma ve yazma erişimi	Azure Pipelines, GitHub'da görüntülenecek kendi derleme, test ve kod kapsamı sonuçlarını okur ve yazar.
Çekme isteklerine okuma ve yazma erişimi	Azure Pipelines, yalnızca kasıtlı eyleminiz üzerine GitHub deponuzun seçili bir dalı için kaydedilmiş bir YAML dosyası için çekme isteği oluşturarak işlem hattı oluşturmayı basitleştirir. İşlem hatları, çekme istekleriyle ilişkili derleme özetlerinde görüntülenecek istek meta verilerini alır.

GitHub Uygulaması yükleme sorunlarını giderme

GitHub şu gibi bir hata görüntüleyebilir:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Bu, GitHub Uygulamasının büyük olasılıkla kuruluşunuz için zaten yüklü olduğu anlamına gelir. Kuruluştaki bir depo için işlem hattı oluşturduğunuzda GitHub Uygulaması otomatik olarak GitHub'a bağlanmak için kullanılır.

Birden çok Azure DevOps kuruluşunda ve projesinde işlem hatları oluşturma

GitHub Uygulaması yüklendikten sonra, farklı Azure DevOps kuruluşlarında ve projelerinde kuruluşun depoları için işlem hatları oluşturulabilir. Ancak, birden çok Azure DevOps kuruluşunda tek bir depo için işlem hatları oluşturursanız, GitHub işlemeleri veya çekme istekleri tarafından yalnızca ilk kuruluşun işlem hatları otomatik olarak tetiklenebilir. İkincil Azure DevOps kuruluşlarında el ile veya zamanlanmış derlemeler hala mümkündür.

OAuth kimlik doğrulaması

OAuth, kişisel GitHub hesabınızdaki depolara başlamak için en basit kimlik doğrulama türüdür. GitHub durum güncelleştirmeleri kişisel GitHub kimliğiniz adına gerçekleştirilir. İşlem hatlarının çalışmaya devam etmesi için depo erişiminizin etkin kalması gerekir. Denetimler gibi bazı GitHub özellikleri OAuth ile kullanılamaz ve GitHub Uygulaması gerektirir.

OAuth kullanmak için, bir işlem hattı oluştururken depo listesinin altındaki Farklı bir bağlantı seçin seçin. Ardından GitHub'da oturum açmak ve OAuth ile yetkilendirmek için Yetkile'yi seçin. OAuth bağlantısı daha sonra kullanmak üzere Azure DevOps projenize kaydedilir ve oluşturulan işlem hattında kullanılır.

GitHub'da gereken izinler

Sürekli tümleştirme ve çekme isteği tetikleyicileri olan bir GitHub deposu için işlem hattı oluşturmak için gerekli GitHub izinlerinin yapılandırılmış olması gerekir. Aksi takdirde, işlem hattı oluşturulurken depo listesinde görünmez. Deponun kimlik doğrulama türüne ve sahipliğine bağlı olarak uygun erişimin yapılandırıldığından emin olun.

• Depo kişisel GitHub hesabınızdaysa, en az bir kez kişisel GitHub hesabı kimlik bilgilerinizi kullanarak OAuth ile GitHub'da kimlik doğrulaması yapın. Bu, GitHub > Yetkilendirme > Yeni hizmet bağlantısı > İşlem Hatları > Hizmet bağlantıları altındaki Azure DevOps proje ayarlarında yapılabilir. Azure Pipelines'a "İzinler" altındaki depolarınıza erişim izni burada.

• Depo başka birinin kişisel GitHub hesabındaysa, en az bir kez, diğer kişinin kişisel GitHub hesabı kimlik bilgilerini kullanarak OAuth ile GitHub'da kimlik doğrulaması yapması gerekir. Bu, GitHub > Yetkilendirme > Yeni hizmet bağlantısı > İşlem Hatları > Hizmet bağlantıları altındaki Azure DevOps proje ayarlarında yapılabilir. Diğer kişinin azure pipelines'aburada "İzinler" altında depolarına erişim izni vermesi gerekir. Deponun ayarlarına "ortak çalışanlar" altında ortak çalışan olarak eklenmelisiniz. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin.

• Depo sahibi olduğunuz bir GitHub kuruluşundaysa, en az bir kez kişisel GitHub hesabı kimlik bilgilerinizi kullanarak OAuth ile GitHub'da kimlik doğrulaması yapın. Bu, GitHub > Yetkilendirme > Yeni hizmet bağlantısı > İşlem Hatları > Hizmet bağlantıları altındaki Azure DevOps proje ayarlarında yapılabilir. Burada"Kuruluş erişimi" altında kuruluşunuza Azure Pipelines erişimi verme. Deponun ayarlarına "ortak çalışanlar ve ekipler" bölümünden ortak çalışan olarak eklenmelidir veya ekibiniz eklenmelidir.

• Depo, başka birinin sahip olduğu bir GitHub kuruluşundaysa, en az bir kez GitHub kuruluş sahibinin kişisel GitHub hesabı kimlik bilgilerini kullanarak OAuth ile GitHub'da kimlik doğrulaması yapması gerekir. Bu, GitHub > Yetkilendirme > Yeni hizmet bağlantısı > İşlem Hatları > Hizmet bağlantıları altındaki Azure DevOps proje ayarlarında yapılabilir. Kuruluş sahibi, burada"Kuruluş erişimi" altında kuruluşa Azure Pipelines erişimi vermelidir. Deponun ayarlarına "ortak çalışanlar ve ekipler" bölümünden ortak çalışan olarak eklenmelidir veya ekibiniz eklenmelidir. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin.

OAuth erişimini iptal etme

Azure Pipelines'ı OAuth kullanma yetkisi verdikten sonra, daha sonra iptal etmek ve daha fazla kullanımı önlemek için GitHub ayarlarınızda OAuth Apps adresini ziyaret edin. Azure DevOps proje ayarlarınızda GitHub hizmet bağlantıları listesinden de silebilirsiniz.

Kişisel erişim belirteci (PAT) kimlik doğrulaması

PAT, OAuth ile etkili bir şekilde aynıdır, ancak Azure Pipelines'a hangi izinlerin verildiğini denetlemenize olanak sağlar. Derlemeler ve GitHub durum güncelleştirmeleri kişisel GitHub kimliğiniz adına gerçekleştirilir. Derlemelerin çalışmaya devam etmesi için depo erişiminizin etkin kalması gerekir.

PAT oluşturmak için GitHub ayarlarınızda kişisel erişim belirteçleri adresini ziyaret edin. Gerekli izinler repo, admin:repo_hook, read:userve user:email' dır. Bunlar, yukarıdaki OAuth kullanılırken gereken izinlerle aynıdır. Oluşturulan PAT'yi panoya kopyalayın ve Azure DevOps proje ayarlarınızda yeni bir GitHub hizmet bağlantısı yapıştırın. Daha sonra geri çağırmak için hizmet bağlantısını GitHub kullanıcı adınızın adını verin. İşlem hatları oluştururken daha sonra kullanmak üzere Azure DevOps projenizde kullanılabilir olacaktır.

GitHub'da gereken izinler

Sürekli tümleştirme ve çekme isteği tetikleyicileri olan bir GitHub deposu için işlem hattı oluşturmak için gerekli GitHub izinlerinin yapılandırılmış olması gerekir. Aksi takdirde, işlem hattı oluşturulurken depo listesinde görünmez. Deponun kimlik doğrulama türüne ve sahipliğine bağlı olarak, aşağıdaki erişimin yapılandırıldığından emin olun.

• Depo kişisel GitHub hesabınızdaysa, PAT'ninKişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: , , ve .

• Depo başka birinin kişisel GitHub hesabındaysa, PAT Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olmalıdır: repo, admin:repo_hook, read:userve user:email. Deponun ayarlarına "ortak çalışanlar" altında ortak çalışan olarak eklenmelisiniz. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin.

• Depo sahibi olduğunuz bir GitHub kuruluşundaysa, PAT Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olmalıdır: repo, admin:repo_hook, read:userve user:email. Deponun ayarlarına "ortak çalışanlar ve ekipler" bölümünden ortak çalışan olarak eklenmelidir veya ekibiniz eklenmelidir.

• Depo başka birinin sahip olduğu bir GitHub kuruluşundaysa, PAT'ninKişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: , , ve . Deponun ayarlarına "ortak çalışanlar ve ekipler" bölümünden ortak çalışan olarak eklenmelidir veya ekibiniz eklenmelidir. Size e-postayla gönderilen bağlantıyı kullanarak ortak çalışma davetini kabul edin.

PAT erişimini iptal etme

Azure Pipelines'ı PAT kullanma yetkisi verdikten sonra, daha sonra silmek ve daha fazla kullanımı önlemek için GitHub ayarlarınızda Kişisel erişim belirteçlerini ziyaret edin. Azure DevOps proje ayarlarınızda GitHub hizmet bağlantıları listesinden de silebilirsiniz.

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.

YAML

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

Şube

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 tetiklendiğinde) 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.

exclude veya batchkullanan 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, main veya yayın dallarına bir değişiklik gönderildiğinde işlem hattı tetiklenir. Ancak, oldile başlayan bir yayınlar dalında değişiklik yapılırsa tetiklenmez.

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

branches listelerinde dal adlarını belirtmeye 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. batch trueolarak ayarlarsanız, bir işlem hattı çalışırken 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, main gönderme A yukarıdaki işlem hattının çalışmasına neden olduğunu belirtelim. İşlem hattı çalışırken depoya ek gönderimler B 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.

Yol

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ünü kullanıyorsanız, yol filtresiyle birlikte tüm dallara filtre uygulamak için branches atlayabilirsiniz.

Yol filtreleri için joker karakterler desteklenir. Örneğin, src/app/**/myapp*ile eşleşen tüm yolları ekleyebilirsiniz. Yol filtrelerini belirtirken joker karakterler (**, *veya ?) 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 /tools dışlarsanız /tools/trigger-runs-on-these
• Yol filtrelerinin sırası önemli değildir.
• Git yolları büyük/küçük harfe duyarlı. 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 branches listelerinde etiketleri belirtmeye ek olarak, dahil etmek veya hariç tutmak için 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

trigger: nonebelirterek CI tetikleyicilerini tamamen geri çevirebilirsiniz.

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

Tetikleyicileri sekmesinde sürekli tümleştirme etkinleştir'i seçerek derlemenin kodu her iade etmesinde çalışmasını istiyorsanız bu tetikleyiciyi etkinleştirin.

Toplu değişiklikler

Değişiklikleri sık sık karşıya yükleyen çok sayıda ekip üyeniz varsa ve çalıştırdığınız derleme sayısını azaltmak istiyorsanız bu onay kutusunu işaretleyin. Bu seçeneği seçerseniz, bir derleme çalışırken sistem çalıştırma tamamlanana kadar bekler ve daha sonra henüz oluşturulmamış tüm değişikliklerin başka bir çalıştırmasını kuyruğa alır.

Değişiklikleri toplu olarak oluşturabilir ve birlikte oluşturabilirsiniz.

Not

Çok aşamalı YAML işlem hattıyla toplu işlem kullanırsanız, sonrakinin başlayabilmesi için çalıştırmanın terminal durumuna ulaşması gerekir. Çok aşamalı bir işlem hattı onaylardan ve uzun süre çalışan dağıtım aşamalarından geçeebildiğinden bu genellikle tercih edilmez. Bu durumlarda, aşağıdaki çözümlerden birini izlemeniz önerilir:

• toplu işlem kullanmayın
• işlem hattını iki ayrı işlem hattına bölme ( biri CI ve biri CD için)
• aşamalarda uygun koşulları ayarlayarak bunları atlayın ve bir çalıştırmanın hızla sonlandırılmasını sağlayın

Dal filtreleri

Derlemeleri tetiklemesini istediğiniz dalları belirtebilirsiniz. Joker karakter kullanmak istiyorsanız dal belirtimini yazın (örneğin, features/modules/*) ve enter tuşuna basın.

Yol filtreleri

Git deponuz Azure Repos veya TFS'deyse, bir derlemeyi tetiklemesini istediğiniz dosya kümesini azaltmak için yol filtreleri de belirtebilirsiniz.

İpuçları:

• 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 /tools dışlarsanız /tools/trigger-runs-on-these
• 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.

Örnek

Örneğin, derlemenizin özellik dallarınızın main ve çoğundaki değişiklikler tarafından tetiklenmesini ancak tümünü tetiklemesini istemezsiniz. Ayrıca, araçlar klasöründeki dosyalarda yapılan değişikliklerle derlemelerin tetiklemesini de istemezsiniz.

Tek tek işlemeler 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şlemelerin iletisine veya açıklamasına [skip ci] dahil 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 Build.Reasonsistem değişkenini kullanarak 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, bir işlem hattının docs klasörüne güncelleştirme gönderdiğinizde 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 karakterle eşleşmesine ve ? tek bir karakterle eşleşmesine olanak sağlar.

• Deseninizi bir YAML işlem hattındaki * ile başlatırsanız, deseni "*-releases"gibi 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ünebilir 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, belirtilen hedef dallardan biriyle bir çekme isteği açıldığında veya böyle bir çekme isteğinde güncelleştirme yapıldığında işlem hattının çalışmasına neden olur.

YAML

Şube

Çekme isteklerinizi doğrularken hedef dalları belirtebilirsiniz. Örneğin, main ve releases/*hedefleyen çekme isteklerini doğrulamak için aşağıdaki pr tetikleyicisini kullanabilirsiniz.

pr:
- main
- releases/*

Bu yapılandırma, ilk kez yeni bir çekme isteği oluşturulduğunda ve çekme isteğinde yapılan her güncelleştirmeden sonra yeni bir çalıştırma başlatır.

Dalın tam adını (örneğin, main) veya joker karakteri (örneğin, releases/*) belirtebilirsiniz.

Not

Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetiklendiğinde) 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.

GitHub, çekme isteği oluşturulduğunda yeni bir başvuru oluşturur. Başvuru, çekme isteğinin kaynak ve hedef dalları arasında birleştirilmiş kod olan birleştirme işlemeişaret eder. Çekme isteği doğrulama işlem hattı, bu başvurunun işaret işlemeyi oluşturur. Bu, işlem hattını çalıştırmak için kullanılan YAML dosyasının da kaynak ve hedef dal arasında bir birleştirme olduğu anlamına gelir. Sonuç olarak, çekme isteğinin kaynak dalındaki YAML dosyasında yaptığınız değişiklikler, hedef daldaki YAML dosyası tarafından tanımlanan davranışı geçersiz kılabilir.

YAML dosyanızda hiçbir pr tetikleyicisi görünmüyorsa, aşağıdaki pr tetikleyicisini yazmış gibi çekme isteği doğrulamaları tüm dallar için otomatik olarak etkinleştirilir. Bu yapılandırma, herhangi bir çekme isteği oluşturulduğunda ve işlemeler herhangi bir etkin çekme isteğinin kaynak dallarına geldiğinde derlemeyi tetikler.

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

Önemli

Dalların alt kümesiyle bir pr tetikleyicisi belirttiğinizde, işlem hattı yalnızca bu dallara güncelleştirme gönderildiğinde tetiklenir.

Belirli dalları dışlamanız gereken daha karmaşık tetikleyiciler için, aşağıdaki örnekte gösterildiği gibi tam söz dizimini kullanmanız gerekir. Bu örnekte, çekme istekleri hedef main veya releases/* doğrulanır ve dal releases/old* dışlanır.

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

Yol

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

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

İpuçları:

• Azure Pipelines, yol dışlama kuralı nedeniyle doğrulama derlemesi çalıştırmamaya karar verince GitHub'a nötr bir durum gönderir. Bu, Azure Pipelines'ın işlemesini tamamladığını belirten GitHub'a açık bir yön sağlar. Daha fazla bilgi için bkz.bir derleme atlandığında GitHub'a nötr durum gönderme .
• Joker kartları artıkyol filtreleri ile desteklenmektedir.
• 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 /tools dışlarsanız /tools/trigger-runs-on-these
• Yol filtrelerinin sırası önemli değildir.
• Git yolları büyük/küçük harfe duyarlı. 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.
• Azure Pipelines, yol dışlama kuralı nedeniyle doğrulama derlemesi çalıştırmamaya karar verince GitHub'a nötr bir durum gönderir.

Birden çok ÇEKME isteği güncelleştirmesi

Aynı çekme isteği için devam eden doğrulama çalıştırmalarını iptal etmek için çekme isteğinde daha fazla güncelleştirme olup olmayacağını belirtebilirsiniz. Varsayılan değer true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Taslak çekme isteği doğrulaması

Varsayılan olarak, çekme isteği tetikleyicileri taslak çekme isteklerinde ve gözden geçirmeye hazır çekme isteklerinde tetiklenir. Taslak çekme isteklerinde çekme isteği tetikleyicilerini devre dışı bırakmak için drafts özelliğini falseolarak ayarlayın.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Çekme isteği doğrulamasını geri çevirme

pr: nonebelirterek çekme isteği doğrulamasını tamamen geri çevirebilirsiniz.

# no PR triggers
pr: none

Daha fazla bilgi için bkz. YAML şeması çekme isteği tetikleyicisi .

Not

pr tetikleyiciniz tetiklenmiyorsa SSSbölümündeki sorun giderme adımlarını izleyin.

Çekme isteği doğrulama tetikleyicisini seçin ve çekme isteklerinde derlemeleri etkinleştirmek için Çekme isteği doğrulama etkinleştir onay kutusunu işaretleyin.

çekme isteği tetikleyicisi

Dahil etmek ve dışlamak için dallar belirtebilirsiniz. Açılan menüden bir dal adı seçin ve dahil et'i veya 'ı uygun şekilde hariç tut'a tıklayın. Dahil edilen dallar için, bu dalı hedefleyen bir çekme isteğine yapılan her göndermede bir derleme tetiklenir.

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:

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

Son olarak, çekme isteğini birleştirdikten sonra, birleştirme işlemesinin iletisi veya açıklaması [skip ci] (veya değişkenlerinden herhangi birini) içermiyorsa, Azure Pipelines hedef dala göndermeler tarafından tetiklenen CI işlem hatlarını çalıştırır.

Korumalı dallar

Bir dalı hedefleyen her işleme veya çekme isteğiyle bir doğrulama derlemesi çalıştırabilir ve hatta bir doğrulama derlemesi başarılı olana kadar çekme isteklerinin birleştirilmesini engelleyebilirsiniz.

GitHub deposu için zorunlu doğrulama derlemelerini yapılandırmak için, bu deponun sahibi, Yönetici rolüne sahip bir ortak çalışan veya Yazma rolüne sahip bir GitHub kuruluş üyesi olmanız gerekir.

1. İlk olarak, depo için bir işlem hattı oluşturun ve durumunun GitHub'a gönderilip GitHub'ın işlem hattının adını bilmesi için en az bir kez derleyin.

2. Ardından, depo ayarlarındaki korumalı dalları yapılandırmaya için GitHub belgelerini izleyin.

   Durum denetimi için Durum denetimleri listesinde işlem hattınızın adını seçin.

   GitHub işlem hattı durumunu

Önemli

İşlem hattınız bu listede görünmüyorsa lütfen aşağıdakilerden emin olun:

• GitHub uygulama kimlik doğrulaması kullanıyorsunuz
• İşlem hattınız son hafta içinde en az bir kez çalıştırılır

Dış kaynaklardan gelen katkılar

GitHub deponuz açık kaynaksa azure DevOps projenizi herkese açık , böylece herkes işlem hattınızın derleme sonuçlarını, günlüklerini ve test sonuçlarını oturum açmadan görüntüleyebilir. Kuruluşunuzun dışındaki kullanıcılar deponuzu çatallayıp çekme istekleri gönderdiğinde, bu çekme isteklerini otomatik olarak doğrulayan derlemelerin durumunu görüntüleyebilir.

Dış kaynaklardan gelen katkıları kabul ederken genel bir projede Azure Pipelines kullanırken dikkat edilmesi gereken noktaları göz önünde bulundurmanız gerekir.

• Erişim kısıtlamaları
• Çatallardan gelen katkıları doğrulama
• Güvenlikle ilgili önemli noktalar

Erişim kısıtlamaları

Azure DevOps genel projelerinde işlem hatlarını çalıştırırken aşağıdaki erişim kısıtlamalarına dikkat edin:

• gizli dizileri : Varsayılan olarak, işlem hattınızla ilişkili gizli diziler çatalların çekme isteği doğrulamaları için kullanılamaz. Bkz. Çatallardan katkıları doğrulama.
• Çapraz proje erişimi: Azure DevOps genel projesindeki tüm işlem hatları, projeyle sınırlı erişim belirteci ile çalıştırılır. Genel bir projedeki işlem hatları derleme yapıtları veya test sonuçları gibi kaynaklara Azure DevOps kuruluşunun diğer projelerinde değil yalnızca proje içinde erişebilir.
• Azure Artifacts paketlerini : İşlem hatlarınızın Azure Artifacts'ten gelen paketlere erişmesi gerekiyorsa, paket akışlarına erişmek için Project Derleme Hizmeti hesabına açıkça izin vermeniz gerekir.

Çatallardan katkılar

Önemli

Bu ayarlar işlem hattınızın güvenliğini etkiler.

bir işlem hattı oluşturduğunuzda, deponuzun çatallarından gelen çekme istekleri için otomatik olarak tetikler. Bu davranışı, güvenliği nasıl etkileyeceğini dikkatle göz önünde bulundurarak değiştirebilirsiniz. Bu davranışı etkinleştirmek veya devre dışı bırakmak için:

1. Azure DevOps projenize gidin. İşlem hatlarıseçin, işlem hattınızı bulun ve Düzenleöğesini seçin.
2. Tetikleyiciler sekmesini seçin.Çekme isteği tetikleyicisini etkinleştirdikten sonra, bu depo çatallarından çekme istekleri oluştur onay kutusunu etkinleştirin veya devre dışı bırakın.

GitHub işlem hatlarında varsayılan olarak, derleme işlem hattınızla ilişkili gizli diziler çatalların çekme isteği derlemelerinde kullanılamaz. Bu gizli diziler GitHub Enterprise Server işlem hatlarıyla varsayılan olarak etkinleştirilir. Gizli diziler şunlardır:

• GitHub deponuza erişimi olan bir güvenlik belirteci.
• İşlem hattınız bunları kullanıyorsa bu öğeler:
  • Hizmet bağlantısı kimlik bilgileri
  • güvenli dosyalar kitaplığındaki dosyalar
  • gizli dizi işaretlenmiş değişkenleri oluşturma

GitHub işlem hatlarında bu önlemi atlamak için Çatal derlemelerinde gizli dizileri kullanılabilir yap onay kutusunu etkinleştirin. Bu ayarın güvenlik üzerindeki etkisine dikkat edin.

Not

Gizli dizilere erişmek için çatal derlemelerini etkinleştirdiğinizde, Azure Pipelines varsayılan olarak çatal derlemeleri için kullanılan erişim belirtecini kısıtlar. Açık kaynaklara normal erişim belirtecinden daha sınırlı erişimi vardır. Çatal derlemelerine normal derlemelerle aynı izinleri vermek için Çatal derlemelerinin normal derlemeler ayarıyla aynı izinlere sahip olmasını etkinleştirin.

Daha fazla bilgi için bkz. Depo koruması - Çatallar.

çatallanmış GitHub depolarından çekme istekleri derlemeyi sınırla denetimi kullanarak işlem hatlarının çatallanmış GitHub depolarından pr'leri nasıl oluşturduğunu merkezi olarak tanımlayabilirsiniz. Kuruluş ve proje düzeyinde kullanılabilir. Şunu seçebilirsiniz:

• Çatallanmış depolardan çekme istekleri derlemeyi devre dışı bırakma
• Çatallanmış depolardan güvenli bir şekilde çekme istekleri oluşturma
• Çatallanmış depolardan çekme istekleri oluşturmak için kuralları özelleştirme

Sprint 229ile başlayarak, işlem hatlarınızın güvenliğini geliştirmek için azure pipelines artıkçatallanmış GitHub depolarından çekme isteklerini otomatik olarak oluşturmaz. Yeni projeler ve kuruluşlar için, Çatallanmış GitHub depolarından çekme isteklerini derlemeyi sınırla ayarının varsayılan değeri Çatallanmış depolardan çekme istekleri derlemeyi devre dışı bırak.

Çatallanmış depolardan güvenli bir şekilde çekme istekleri oluşturma seçeneğini belirlediğinizde, tüm işlem hatları, kuruluş veya proje genelinde gizli diziler çatallanmış depolardan gelen PR'ler için kullanılabilir hale getiremez bu derlemelerin normal derlemelerle aynı izinlere sahip olmasını ve çekme isteği açıklamasıyla tetiklenmesi gerekir. Projeler yine de işlem hatlarının bu tür PR'ler oluşturmasına izin karar verebilir.

Özelleştir seçeneğini belirlediğinizde işlem hattı ayarlarının nasıl kısıtlanacağı tanımlayabilirsiniz. Örneğin, çekme isteği ekip üyesi olmayan ve katkıda bulunan olmayanlara ait olduğunda çatallanmış GitHub deposundan çekme isteği oluşturmak için tüm işlem hatlarının açıklama gerektirdiğinden emin olabilirsiniz. Ancak, gizli dizileri bu tür derlemeler için kullanılabilir hale getirmelerine izin vermeyi seçebilirsiniz. Projeler işlem hatlarının bu tür PR'ler oluşturmasına izin vermemeye veya bunları güvenli bir şekilde derlemeye veya kuruluş düzeyinde belirtilenden daha kısıtlayıcı ayarlara sahip olmasına karar verebilir.

Denetim, mevcut kuruluşlar için kapalıdır. Eylül 2023'ten itibaren, yeni kuruluşlar Çatallanmış depolardan güvenli bir şekilde çekme istekleri derledi varsayılan olarak.

Önemli güvenlik konuları

GitHub kullanıcısı deponuzun çatalını oluşturabilir, deponuzu değiştirebilir ve deponuzda değişiklik önermek için bir çekme isteği oluşturabilir. Bu çekme isteği, tetiklenen derlemenizin bir parçası olarak çalıştırılacak kötü amaçlı kod içerebilir. Bu tür kodlar aşağıdaki yollarla zarara neden olabilir:

• İşlem hattınızdan gizli dizileri sızdırabilirsiniz. Deponuz genel veya güvenilmeyen kullanıcılar derlemeleri otomatik olarak tetikleyen çekme istekleri gönderebiliyorsa, bu riski azaltmak için Gizli dizileri çatal derlemeleri için kullanılabilir yap onay kutusunu etkinleştirmeyin. Bu seçenek varsayılan olarak devre dışıdır.

• Diğer işlem hatlarından kod veya gizli dizileri çalmak için aracıyı çalıştıran makinenin güvenliğini tehlikeye atabilirsiniz. Bunu azaltmak için:

  • Çatallardan çekme istekleri oluşturmak için Microsoft tarafından barındırılan aracı havuzu kullanın. Microsoft tarafından barındırılan aracı makineler bir derlemeyi tamamladıktan hemen sonra silinir, bu nedenle tehlikeye girerlerse kalıcı bir etki olmaz.

  • şirket içinde barındırılan bir aracı kullanmanız gerekiyorsa, deponuz özel değilse ve çekme isteği oluşturucularına güvenmiyorsanız, aynı aracıda gizli dizileri kullanan başka derlemeler ve yayınlar gerçekleştirmayın.

Açıklama tetikleyicileri

Depo ortak çalışanları, bir işlem hattını el ile çalıştırmak için çekme isteğine yorum yapabilir. Bunu yapmak istemenize neden olabilecek bazı yaygın nedenler şunlardır:

• Değişiklikleri gözden geçirilinceye kadar bilinmeyen kullanıcılardan otomatik olarak çekme istekleri oluşturmak istemeyebilirsiniz. Ekip üyelerinizden birinin önce kodlarını gözden geçirmesini ve ardından işlem hattını çalıştırmasını istiyorsunuz. Bu genellikle çatallanmış depolardan katkıda bulunan kod oluştururken güvenlik önlemi olarak kullanılır.
• İsteğe bağlı bir test paketi veya bir doğrulama derlemesi daha çalıştırmak isteyebilirsiniz.

Açıklama tetikleyicilerini etkinleştirmek için aşağıdaki iki adımı izlemeniz gerekir:

1. İşlem hattınız için çekme isteği tetikleyicilerini etkinleştirin ve hedef dalı dışlamadığınızdan emin olun.
2. Azure Pipelines web portalında işlem hattınızı düzenleyin ve Diğer eylemleröğesini seçin Tetikleyiciler. ArdındanÇekme isteği doğrulama altında,çekme isteği oluşturmadan önce Ekip üyesinin açıklamasını gerektir etkinleştirin.
   • Çekme isteği oluşturmadan önce ekip üyesinin açıklamasını istemek için tüm çekme isteklerinde 'ı seçin. Bu iş akışıyla, bir ekip üyesi çekme isteğini inceler ve çekme isteğinin güvenli olduğu kabul edildikten sonra derlemeyi bir açıklamayla tetikler.
   • Yalnızca ekip üyesi olmayan üyelerin çekme isteklerinde' i seçerek yalnızca ekip üyesi olmayan bir üye tarafından çekme isteği yapıldığında ekip üyesinin açıklamasını zorunlu kılır. Bu iş akışında, bir ekip üyesinin bir derlemeyi tetikleyebilmek için ikincil bir ekip üyesinin incelemesine ihtiyacı yoktur.

Bu iki değişiklikle, çekme isteği doğrulama derlemesi otomatik olarak tetiklenmez; yalnızca ekip üyesi olmayanlardan gelen çekme isteklerinde seçilir ve çekme isteği bir ekip üyesi tarafından yapılır. Yalnızca 'Yazma' iznine sahip depo sahipleri ve ortak çalışanlar /AzurePipelines run veya /AzurePipelines run <pipeline-name>ile çekme isteğine yorum yaparak derlemeyi tetikleyebilir.

Azure Pipelines'a açıklamalarda aşağıdaki komutlar yayımlanabilir:

Komut	Sonuç
/AzurePipelines help	Desteklenen tüm komutlar için yardım görüntüleyin.
/AzurePipelines help <command-name>	Belirtilen komut için yardım görüntüleyin.
/AzurePipelines run	Bu depoyla ilişkili ve tetikleyicileri bu çekme isteğini dışlamayan tüm işlem hatlarını çalıştırın.
/AzurePipelines run <pipeline-name>	Tetikleyicileri bu çekme isteğini dışlamadığı sürece belirtilen işlem hattını çalıştırın.

Not

Kısalık için, /AzurePipelinesyerine /azp kullanarak yorum yapabilirsiniz.

Önemli

Bu komutlara verilen yanıtlar çekme isteği tartışmasında yalnızca işlem hattınız Azure Pipelines GitHub Appkullanıyorsa görünür.

Çekme isteği açıklama tetikleyicileriyle ilgili sorunları giderme

Gerekli depo izinlerine sahipseniz ancak işlem hatları yorumlarınız tarafından tetiklenmiyorsa, üyeliğinizin deponun kuruluşunda genel olduğundan emin olun veya kendinizi doğrudan depo işbirlikçisi olarak ekleyin. İşlem hatları, doğrudan ortak çalışanlar olmadığı veya doğrudan işbirliği yapan bir ekibİn üyesi olmadığı sürece özel kuruluş üyelerini göremez. GitHub kuruluş üyeliğinizi burada özel olan genel olarak değiştirebilirsiniz (Your-Organization kuruluşunuzun adıyla değiştirin): https://github.com/orgs/Your-Organization/people.

Bilgilendirme çalıştırmaları

Bilgilendirme amaçlı çalıştırma, Azure DevOps'un bir YAML işlem hattının kaynak kodunu alamadığını bildirir. Kaynak kodu alma işlemi, gönderilen işleme gibi dış olaylara yanıt olarak gerçekleşir. Kod değişiklikleri olup olmadığını denetlemek ve zamanlanmış çalıştırma başlatıp başlatmamak gibi iç tetikleyicilere yanıt olarak da gerçekleşir. Kaynak kodu alma işlemi, git deposu sağlayıcısı tarafından sık sık azaltma isteğinde bulunulması nedeniyle birden çok nedenden dolayı başarısız olabilir. Bilgi amaçlı çalıştırmanın varlığı, Azure DevOps'un işlem hattını çalıştıracağını göstermez.

Bilgilendirme çalıştırması aşağıdaki ekran görüntüsünde olduğu gibi görünür.

Aşağıdaki özniteliklerle bir bilgilendirme çalıştırmasını tanıyabilirsiniz:

• Durum Canceled
• Süre < 1s
• Çalıştırma adı aşağıdaki metinlerden birini içerir:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• Çalıştırma adı genellikle YAML işlem hattı yükünün başarısız olmasına neden olan BitBucket / GitHub hatasını içerir
• Aşama / iş / adım yok

bilgilendirme çalıştırmaları hakkında daha fazla bilgi edinin.

Kasa

İş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, checkout: none yerleşik kullanıma almayı dışlayıp 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. Eklenen kopyayı kullanmak yerine kendi Git'inizi sağlamayı tercih ediyorsanız, System.PreferGitFromPathtrueolarak ayarlayın. Bu ayar Windows olmayan aracılarda her zaman geçerlidir.

Kullanıma alma yolu

YAML

Tek bir depoya göz atıyorsanız, kaynak kodunuz varsayılan olarak sadlı bir dizinde kullanıma alınır. YAML işlem hatları için, pathile checkout belirterek bunu değiştirebilirsiniz. Belirtilen yol $(Agent.BuildDirectory)göredir. Örneğin: kullanıma alma yolu değeri mycustompath ve $(Agent.BuildDirectory)C:\agent\_work\1ise, kaynak kod C:\agent\_work\1\mycustompathiçinde kullanıma alınır.

Birden çok checkout adımı kullanıyor ve birden çok depoyu kullanıma alıp pathkullanarak klasörü açıkça belirtmiyorsanız, her depo, deponun adını taşıyan bir s alt klasörüne yerleştirilir. Örneğin, tools ve codeadlı iki depoyu kullanıma alırsanız, kaynak kodu C:\agent\_work\1\s\tools kullanıma alınır ve C:\agent\_work\1\s\code.

Lütfen, kullanıma alma yolu değerinin $(Agent.BuildDirectory)üzerindeki dizin düzeylerini aşacak şekilde ayarlanamayacağını unutmayın; bu nedenle path\..\anotherpath geçerli bir ödeme yolu (C:\agent\_work\1\anotherpath) ile sonuçlanır, ancak ..\invalidpath gibi bir değer (C:\agent\_work\invalidpath) olmaz.

İşlem hattınızın Kullanıma Alma adımında path ayarını 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 ayar klasik düzenleyicide yapılandırılamaz. Kaynak kodunuz, $(Agent.BuildDirectory)göre sadlı bir dizinde kullanıma alınır. Örneğin: $(Agent.BuildDirectory)C:\agent\_work\1ise, kaynak kodu C:\agent\_work\1\mycustompathiçinde kullanıma alınır.

Alt modüller

YAML

alt modüllerinden dosya indirmek istiyorsanız, işlem hattınızın Kullanıma Alma adımında ayarını 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üllerinden dosya indirmek istiyorsanız, Alt Modüller ayarını işlem hattınızdaki kaynakları al görevinin özelliklerinden yapılandırabilirsiniz.

Alt Modülleri Yapılandır ayarını

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 bilgileri gerekmeyen genel, kimliği doğrulanmamış bir depo.

• Kimliği Doğrulandı:

  • 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. Mesela

    • Bu kullanıma alınmış olacaktır: 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 üzerindeki etkileri hakkında daha fazla bilgi için bkz. Access 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 pat:ön ekini ekleyin. Ardından, temel kimlik doğrulama belirteci oluşturmak için bu ön ekli dizeyi base64 kodlaması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?A: Alt modül kimlik bilgilerini özel derleme aracınızda yüklü bir Git kimlik bilgisi yöneticisinde depolamak genellikle etkili olmaz, bunun için 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 --tags seçeneğini kullanır. 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.

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

YAML

İşlem hattınızın Kullanıma Alma adımında fetchTags ayarını yapılandırabilirsiniz.

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

steps:
- checkout: self
  fetchTags: true

Bu ayarı, işlem hattı ayarları kullanıcı arabirimindeki etiketleri eşitle seçeneğini kullanarak da yapılandırabilirsiniz.

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

   

2. yamlseçin Kaynak al.

   

3. Eşitleme etiketleri ayarını yapılandırın.

   

Not

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

Eşitleme etiketleri ayarını İşlem hattınızdaki Kaynakları al görevinin özelliklerinden yapılandırabilirsiniz.

Varsayılan davranış

• Eylül 2022'de yayımlanan Azure DevOps sprint 209yayımlanmadan önce oluşturulan mevcut işlem hatları için, etiketleri eşitlemek için varsayılan değer, trueEşitleme etiketleri seçenekleri eklenmeden önceki mevcut davranışla aynı kalır.
• Azure DevOps sprint sürümü 209'undan sonra oluşturulan yeni işlem hatları için etiketleri eşitlemek için varsayılan değer false.

Not

checkout adımınızda fetchTags açıkça ayarlarsanız, 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 git fetch --depth=nsonucunu döndürür. 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ştirme sonra oluşturulan yeni işlem hatları, Sığ getirme varsayılan olarak etkinleştirildi ve 1 derinliğiyle yapılandırıldı. Ö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.

YAML

İşlem hattınızın Kullanıma Alma adımında fetchDepth ayarını 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

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

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

   

2. yamlseçin Kaynak al.

   

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

   

Not

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

Sığ getirme ayarını İşlem hattınızdaki Kaynakları al görevinin özelliklerinden yapılandırabilirsiniz.

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.

YAML

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

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

İşlem hattınızdaki Kaynakları al görevinin özelliklerinden Kaynakları eşitleme ayarını seçin.

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, oluşturmak için kullandığınız görevin veya aracın Temizle 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 aracı kullanıyorsanız temizleme işlemi etkili değildir çünkü her seferinde yeni bir aracı alırsınız.

YAML

İşlem hattınızın Kullanıma Alma adımında clean ayarını 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 olarak ayarlandığında derleme işlem hattı $(Build.SourcesDirectory)içindeki 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 İşiworkspace 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.

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

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

• Tüm: siler ve yeniden oluşturur. Bu, her derleme için yeni, yerel bir Git deposunun başlatılmasına neden olur.

İşlem hattınızdaki Kaynakları al görevinin özelliklerinden Temiz ayarını seçin ve aşağıdaki seçeneklerden birini belirleyin.

• Sources: Derleme işlem hattı, $(Build.SourcesDirectory)içindeki tüm 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
  

• Sources and output directory: Yukarıdaki Sources seçeneğiyle aynı işlem artı: $(Build.BinariesDirectory)siler ve yeniden oluşturur. $(Build.ArtifactStagingDirectory) ve $(Common.TestResultsDirectory), bu ayarlardan herhangi biri ne olursa olsun her derlemeden önce her zaman silinir ve yeniden oluşturulur.

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

• Tüm derleme dizinleri: $(Agent.BuildDirectory)siler ve yeniden oluşturur. 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.

YAML

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 seçerek klasik düzenleyiciye erişebilirsiniz.

Klasik düzenleyiciden YAMLseçin, Kaynak al görevi seçin ve ardından istenen özellikleri orada yapılandırın.

Etiket kaynakları ayarını İşlem hattınızdaki Kaynakları al görevinin özelliklerinden yapılandırabilirsiniz.

Etiket biçiminde kapsamı "Tümü" olan 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. ,değişkenleri sekmesinde sizin tarafınızdan tanımlanabilir.

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

Bazı derleme değişkenleri geçerli bir etiket olmayan bir değer verebilir. Örneğin, $(Build.RequestedFor) ve $(Build.DefinitionName) gibi 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şvuru 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.

Önceden tanımlanmış değişkenler

GitHub deposu oluşturduğunuzda, önceden tanımlanmış değişkenlerin çoğu işleriniz tarafından kullanılabilir. Ancak Azure Pipelines, GitHub'da güncelleştirme yapan bir kullanıcının kimliğini tanımadığından, aşağıdaki değişkenler kullanıcının kimliği yerine sistem kimliğine ayarlanır:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Durum güncelleştirmeleri

Azure Pipelines'ın GitHub'a geri göndermesi gereken iki durum türü vardır: temel durumlar ve GitHub Denetim Çalıştırmaları. GitHub Denetimleri işlevi yalnızca GitHub Uygulamaları ile kullanılabilir.

İşlem hattı durumları GitHub kullanıcı arabiriminde çeşitli yerlerde gösterilir.

• PR'ler için çekme isteği konuşmaları sekmesinde görüntülenir.
• Tek tek işlemeler için bunlar, deponun işlemeler sekmesindeki işleme süresinden sonra durum işaretinin üzerine gelindiğinde görüntülenir.

PAT veya OAuth GitHub bağlantıları

PAT veya OAuth GitHub bağlantılarını kullanan işlem hatları için, durumlar çalıştırmayı tetikleyen işleme/çekme isteğine geri postalanır. GitHub durum API'si bu tür güncelleştirmeleri göndermek için kullanılır. Bu durumlar sınırlı bilgi içerir: işlem hattı durumu (başarısız, başarılı), derleme işlem hattına geri bağlanmak için URL ve durumun kısa bir açıklaması.

PAT veya OAuth GitHub bağlantılarının durumları yalnızca çalıştırma düzeyinde gönderilir. Başka bir deyişle, çalıştırmanın tamamı için tek bir durumun güncelleştirilmiş olması gerekir. Bir çalıştırmada birden çok işiniz varsa, her iş için ayrı bir durum gönderemezsiniz. Ancak, birden çok işlem hattı aynı işlemeye ayrı durumlar gönderebilir.

GitHub Denetimleri

Azure Pipelines GitHub uygulaması kullanılarak ayarlanan işlem hatları için durum, GitHub Denetimleri biçiminde geri gönderiliyor. GitHub Denetimleri işlem hattı durumu ve test, kod kapsamı ve hatalar hakkında ayrıntılı bilgi göndermeye olanak sağlar. GitHub Denetimleri API'sini buradabulabilirsiniz.

GitHub Uygulamasını kullanan her işlem hattı için Denetimler, genel çalıştırma ve bu çalıştırmadaki her iş için geri gönderiliyor.

GitHub, çekme isteği/işleme için bir veya daha fazla Denetim Çalıştırması başarısız olduğunda üç seçeneğe izin verir. Tek tek Denetimi "yeniden çalıştırmayı" seçebilir, bu çekme isteğinde/işlemede başarısız olan tüm Denetimleri yeniden çalıştırabilir veya başlangıçta başarılı olup olmadıklarına bakılmaksızın tüm Denetimleri yeniden çalıştırabilirsiniz.

Çalıştırmayı Denetle adının yanındaki "Yeniden Çalıştır" bağlantısına tıklanması, Azure Pipelines'ın Çalıştırmayı Denetle'yi oluşturan çalıştırmayı yeniden denemesine neden olur. Sonuç çalıştırması aynı çalıştırma numarasına sahip olur ve kaynak kodun, yapılandırmanın ve YAML dosyasının ilk derlemeyle aynı sürümünü kullanır. Yalnızca ilk çalıştırmada başarısız olan işler ve bağımlı aşağı akış işleri yeniden çalıştırılır. "Tüm başarısız denetimleri yeniden çalıştır" bağlantısına tıklanması aynı etkiye sahip olur. Bu, Azure Pipelines kullanıcı arabiriminde "Çalıştırmayı yeniden dene" seçeneğine tıklamayla aynı davranıştır. "Tüm denetimleri yeniden çalıştır" seçeneğine tıklanması, yeni bir çalıştırma numarasıyla yeni bir çalıştırmaya neden olur ve yapılandırma veya YAML dosyasındaki değişiklikleri alır.

Sınırlama

• En iyi performans için tek bir depoda en fazla 50 işlem hattı kullanmanızı öneririz. Kabul edilebilir performans için tek bir depoda en fazla 100 işlem hattı önerilir. Bir depoya gönderimi işlemek için gereken süre, bu depodaki işlem hatlarının sayısıyla artar. Bir depoya gönderim olduğunda Azure Pipelines'ın herhangi birinin çalıştırılması gerekip gerekmediğini öğrenmek için bu depodaki tüm YAML işlem hatlarını yüklemesi gerekir ve her işlem hattının yüklenmesi bir performans cezasına neden olur. Performans sorunlarına ek olarak, tek bir depoda çok fazla işlem hattı olması GitHub tarafında azaltmaya neden olabilir çünkü Azure Pipelines kısa sürede çok fazla istekte bulunabilir.

• kullanımı genişletir ve şablonları bir işlem hattına dahil etmek, Azure Pipelines'ın GitHub API istekleri yapma hızını etkiler ve GitHub tarafında azaltmaya yol açabilir. İşlem hattını çalıştırmadan önce Azure Pipelines'ın tüm YAML kodunu oluşturması ve bu nedenle tüm şablon dosyalarını getirmesi gerekir.

• Azure Pipelines, bir depodan Azure DevOps Portalı'ndaki açılan listelere en fazla 2000 dal yükler. Örneğin, el ile ve zamanlanmış derlemeler ayarı için Varsayılan dalı için dal seçin penceresinde veya işlem hattını el ile çalıştırırken dal seçerken.

  İstediğiniz dalı listede görmüyorsanız, el ile ve zamanlanmış derlemeler alanı için varsayılan dal istediğiniz dal adını el ile yazın.

  Üç noktaya tıklayıp Dal seçin iletişim kutusunu açar ve açılan listeden geçerli bir dal seçmeden kapatırsanız, Bazı ayarların iletiye ve dikkate alınması gerektiğini görebilirsiniz. Bu ayar,el ile ve zamanlanmış derlemeler için Varsayılan Dal altında iletiyi gerektirir. Bu iletiyi geçici olarak çözmek için işlem hattını yeniden açın ve el ile ve zamanlanmış derlemeler alanına doğrudan varsayılan dalını girin.

SSS

GitHub tümleştirmesi ile ilgili sorunlar aşağıdaki kategorilere ayrılır:

• bağlantı türlerini: işlem hattımı GitHub'a bağlamak için hangi bağlantı türünü kullandığımdan emin değilim.
• Başarısız tetikleyiciler: Depoya güncelleştirme gönderdiğimde işlem hattım tetiklenmiyor.
• Kullanıma alma başarısız: İş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 kaynak/YAML'nin beklenmeyen bir sürümünü kullanıyor.
• Eksik durum güncelleştirmeleri: GitHub PR'lerim Azure Pipelines durum güncelleştirmesi bildirmediği için engellendi.

Bağlantı türleri

Tetikleyicilerle ilgili sorunları gidermek için işlem hattım için kullandığım GitHub bağlantısının türünü nasıl bilebilirim?

Tetikleyicilerle ilgili sorunları gidermek, işlem hattınızda kullandığınız GitHub bağlantısının türüne bağlıdır. Bağlantı türünü belirlemenin iki yolu vardır: GitHub'dan ve Azure Pipelines'tan.

• GitHub'dan: GitHub uygulamasını kullanmak üzere bir depo ayarlandıysa PR'ler ve işlemelerdeki durumlar Çalıştırmaları Denetle olacaktır. Depoda OAuth veya PAT bağlantıları ile ayarlanmış Azure Pipelines varsa, durumlar "eski" durum stili olacaktır. Durumların Çalıştırmaları Denetle mi yoksa basit durumlar mı olduğunu belirlemenin hızlı bir yolu GitHub PR'sinde "konuşma" sekmesine bakmaktır.

  • "Ayrıntılar" bağlantısı Denetimler sekmesine yeniden yönlendiriliyorsa, bu bir Çalıştırmayı Denetle'dir ve depo uygulamayı kullanıyordur.
  • "Ayrıntılar" bağlantısı Azure DevOps işlem hattına yönlendirilirse, durum "eski stil" durumudur ve depo uygulamayı kullanmıyor demektir.

• Azure Pipelines'dan: Azure Pipelines kullanıcı arabirimindeki işlem hattını inceleyerek bağlantı türünü de belirleyebilirsiniz. İşlem hattının düzenleyicisini açın. İşlem hattının klasik düzenleyicisini açmak için Tetikleyiciler'ni seçin. Ardından YAML sekmesini ve ardından Kaynakları al adımını . Bağlantı kullanılarak yetkilendirilmiş: işlem hattını GitHub ile tümleştirmek için kullanılan hizmet bağlantısını gösteren bir başlık göreceksiniz. Hizmet bağlantısının adı bir köprüdür. Hizmet bağlantısı özelliklerine gitmek için seçin. Hizmet bağlantısının özellikleri, kullanılan bağlantı türünü gösterir:

  • Azure Pipelines uygulaması GitHub uygulama bağlantısını gösterir
  • oauth OAuth bağlantısını gösterir
  • personalaccesstoken PAT kimlik doğrulamayı gösterir

İşlem hattımı OAuth yerine GitHub uygulamasını kullanacak şekilde nasıl değiştirebilirim?

OAuth veya PAT bağlantısı yerine GitHub uygulaması kullanmak, GitHub ile Azure Pipelines arasında önerilen tümleştirmedir. GitHub uygulamasına geçmek için şu adımları izleyin:

1. buradan gidin ve uygulamayı deponuzun GitHub kuruluşuna yükleyin.
2. Yükleme sırasında bir Azure DevOps kuruluşu ve projesi seçmek için Azure DevOps'a yönlendirilirsiniz. Uygulamayı kullanmak istediğiniz klasik derleme işlem hattını içeren kuruluşu ve projeyi seçin. Bu seçenek GitHub Uygulaması yüklemesini Azure DevOps kuruluşunuzla ilişkilendirir. Yanlış seçim yaparsanız, GitHub uygulamasını GitHub kuruluşunuzdan kaldırıp baştan başlamak için bu sayfayı ziyaret edebilirsiniz.
3. Görüntülenen sonraki sayfada yeni bir işlem hattı oluşturmaya devam etmeniz gerekmez.
4. İşlem hatları sayfasını ziyaret ederek (örneğin, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)) işlem hattınızı seçip Düzenle'ye tıklayarak işlem hattınızı düzenleyin.
5. Bu bir YAML işlem hattıysa, klasik düzenleyiciyi açmak için tetikleyiciler menüsünü seçin.
6. İşlem hattında "Kaynakları al" adımını seçin.
7. "Bağlantı kullanılarak yetkilendirildi" metninin bulunduğu yeşil çubukta "Değiştir" seçeneğini belirleyin ve uygulamayı yüklediğiniz GitHub kuruluşuyla aynı ada sahip GitHub Uygulaması bağlantısını seçin.
8. Araç çubuğunda "Kaydet ve kuyruk" ve ardından "Kaydet ve kuyruk" öğesini seçin. Başarılı olduğundan emin olmak için kuyruğa alınan işlem hattı çalıştırmasının bağlantısını seçin.
9. Bir derlemenin "Denetimler" bölümünde başarıyla kuyruğa alındığını doğrulamak için GitHub deponuzda çekme isteği oluşturun (veya kapatın ve yeniden açın).

Azure Pipelines'da seçmem için neden bir GitHub deposu görüntülenmiyor?

Deponun kimlik doğrulama türüne ve sahipliğine bağlı olarak, belirli izinler gereklidir.

• GitHub Uygulamasını kullanıyorsanız bkz. GitHub Uygulaması kimlik doğrulaması.
• OAuth kullanıyorsanız bkz. OAuth kimlik doğrulaması.
• PTS kullanıyorsanız bkz. Kişisel erişim belirteci (PAT) kimlik doğrulaması.

İşlem hattı oluşturma sırasında bir depo seçtiğim zaman "{repo-name} deposu başka bir Azure DevOps kuruluşundaki Azure Pipelines GitHub Uygulaması ile kullanılıyor" hatasını alıyorum.

Bu, deponuzun zaten farklı bir kuruluştaki bir işlem hattıyla ilişkili olduğu anlamına gelir. Bu depodaki CI ve PR olayları, diğer kuruluşa teslim edilecekleri için çalışmaz. İşlem hattı oluşturmaya devam etmeden önce diğer kuruluşla eşlemeyi kaldırmak için izlemeniz gereken adımlar aşağıdadır.

1. GitHub deponuzda bir çekme isteği açın ve açıklamasını /azp whereyapın. Bu, deponun eşlendiği Azure DevOps kuruluşunu geri bildirir.

2. Eşlemeyi değiştirmek için uygulamayı GitHub kuruluşundan kaldırın ve yeniden yükleyin. Yeniden yüklerken, Azure DevOps'a yeniden yönlendirildiğinde doğru kuruluşu seçtiğinizden emin olun.

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ı arabirimiişlem hattı ayarları tarafından geçersiz kılınıyor ? İşlem hattınızı düzenlerken ...'ı seçin ve ardından tetikleyicileri.

  İşlem hattı ayarları kullanıcı arabirimini

  Deponuz için kullanılabilir tetikleyici türleri (Sürekli tümleştirmeveya çekme isteği doğrulama) için buradan YAML tetikleyicisini geçersiz kıl denetleyin.

  Buradan YAML tetikleyicilerini geçersiz kıl'ı

• İşlem hattını GitHub'a bağlamak için GitHub uygulama bağlantısını mı kullanıyorsunuz? Sahip olduğunuz bağlantı türünü belirlemek için bkz. Bağlantı türleri. GitHub uygulama bağlantısı kullanıyorsanız şu adımları izleyin:

  • Eşleme GitHub ile Azure DevOps arasında düzgün ayarlandı mı? GitHub deponuzda bir çekme isteği açın ve açıklamasını /azp whereyapın. Bu, deponun eşlendiği Azure DevOps kuruluşunu geri bildirir.

    • Uygulamayı kullanarak bu depoyu oluşturmak için hiçbir kuruluş ayarlanmadıysa https://github.com/<org_name>/<repo_name>/settings/installations gidin ve uygulamanın yapılandırmasını tamamlayın.

    • Farklı bir Azure DevOps kuruluşu bildirilirse, birisi farklı bir kuruluşta bu depo için bir işlem hattı oluşturmuş demektir. Şu anda bir GitHub deposunu yalnızca tek bir DevOps kuruluşuyla eşleyebiliriz. Yalnızca ilk Azure DevOps kuruluşunun işlem hatları otomatik olarak tetiklenebilir. Eşlemeyi değiştirmek için uygulamayı GitHub kuruluşundan kaldırın ve yeniden yükleyin. Yeniden yüklerken, Azure DevOps'a yeniden yönlendirildiğinde doğru kuruluşu seçtiğinizden emin olun.

• İşlem hattını GitHub'a bağlamak için OAuth veya PAT mi kullanıyorsunuz? Sahip olduğunuz bağlantı türünü belirlemek için bkz. Bağlantı türleri. GitHub bağlantısı kullanıyorsanız şu adımları izleyin:

  1. OAuth ve PAT bağlantıları, güncelleştirmeleri Azure Pipelines'a iletmek için web kancalarını temel alır. GitHub'da deponuzun ayarlarına ve ardından Web Kancaları'na gidin. Web kancalarının var olduğunu doğrulayın. Genellikle üç web kancası görmeniz gerekir: gönderme, pull_request ve issue_comment. Aksi takdirde, hizmet bağlantısını yeniden oluşturmanız ve işlem hattını yeni hizmet bağlantısını kullanacak şekilde güncelleştirmeniz gerekir.

  2. GitHub'daki web kancalarının her birini seçin ve kullanıcının işlemesine karşılık gelen yükün mevcut olduğunu ve Azure DevOps'a başarıyla gönderildiğini doğrulayın. Olay Azure DevOps'a iletilemiyorsa burada bir hata görebilirsiniz.

• Azure DevOps'tan gelen trafik GitHub tarafından kısıtlanabilir. Azure Pipelines, GitHub'dan bir bildirim aldığında GitHub ile iletişime geçerek depo ve YAML dosyası hakkında daha fazla bilgi getirmeye çalışır. Çok sayıda güncelleştirme ve çekme isteği içeren bir deponuz varsa, bu tür azaltma nedeniyle bu çağrı başarısız olabilir. Bu durumda, toplu işlem veya daha katı yol/dal filtreleri kullanarak derlemelerin sıklığını azaltıp azaltamadığını görün.

• İş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 ve ardından şu ek adımları izleyin:

• Çekme isteğinizde birleştirme çakışmaları var mı? İşlem hattını tetiklememiş 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? Sorunun tek bir işlem hattına özgü olup olmadığını veya projenizdeki tüm işlem hatlarında veya depolarda yaygın olup olmadığını görerek genellikle gecikmeyi 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. Gecikmenin nedenlerinden bazıları şunlardır:

  • durum sayfamızda bir hizmet kesintisi yaşıyoruz. 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.
  • Deponuz çok fazla YAML işlem hattı içeriyor. En iyi performans için tek bir depoda en fazla 50 işlem hattı kullanmanızı öneririz. Kabul edilebilir performans için tek bir depoda en fazla 100 işlem hattı önerilir. ne kadar çok işlem hattı varsa, bu depoya gönderimin işlenmesi o kadar yavaş olur. Bir depoya gönderim olduğunda Azure Pipelines'ın herhangi birinin çalıştırılması gerekip gerekmediğini ve her yeni işlem hattının performans cezasına neden olup olmadığını öğrenmek için bu depodaki tüm YAML işlem hatlarını yüklemesi gerekir.

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

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 düzeltebilirim?

remote: Repository not found.
fatal: repository <repo> not found

Bunun nedeni GitHub kesintisi olabilir. GitHub'daki depoya erişmeyi deneyin ve erişebildiğinizden emin olun.

Yanlış sürüm

İşlem hattında YAML dosyasının yanlış bir sürümü kullanılıyor. Neden böyle oldu?

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

Eksik durum güncelleştirmeleri

Azure Pipelines durumu güncelleştirmediğinden GitHub'daki çekme isteğim engellendi.

Bu, Azure DevOps'un GitHub ile iletişim kuramamasına neden olan geçici bir hata olabilir. GitHub uygulamasını kullanıyorsanız GitHub'a iade işlemini yeniden deneyin. Veya sorunun çözülip çözülemediğini görmek için pr'ye önemsiz bir güncelleştirme yapın.

İlgili makaleler

• zamanlanmış tetikleyicileri
• İşlem hattı tamamlama tetikleyicilerini