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 hattı tümleştirmesi konusunda yeniyseniz İlk işlem hattınızı oluşturma bölümünde yer alan adımları 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şlar

GitHub'ın yapısı, depo içeren kuruluşlardan ve kullanıcı hesaplarından oluşur. GitHub'ın belgelerine bakın.

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

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

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

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. gibi https://dev.azure.com/your-organizationbir URL'si olacaktır.
2. DevOps kuruluşunda depolarınızın adını taşıyan projeler oluşturun. gibi https://dev.azure.com/your-organization/your-repositoryURL'leri olacaktır.
3. DevOps Projesi'nde GitHub kuruluşundan ve oluşturdukları depodan (gibi your-organization.your-repository) 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. Örneğin:

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

Kullanıcılar

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 adresinde bulunur https://github.com/orgs/your-organization/people (değiştir your-organization).

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

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	Üyesi Project Collection Administrators
Faturalama yöneticisi	Üyesi Project Collection Administrators
Üye	öğesinin üyesi Project Collection Valid Users. Varsayılan olarak, Üye grubunun yeni proje oluşturma izni yoktur. İzni değiştirmek için, grubun Create new projects iznini olarak Allowayarlayı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 adresinde https://dev.azure.com/your-organization/_settings/security bulunur (değiştir your-organization).

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	Üyesi Project Collection Administrators

GitHub deposu izinleri

GitHub depo izinleri (replace your-organization ve your-repository) konumunda https://github.com/your-organization/your-repository/settings/collaboration bulunur.

DevOps proje izinleri (replace your-organization ve your-project) konumunda https://dev.azure.com/your-organization/your-project/_settings/security bulunur.

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

GitHub deposu izni	DevOps projesi eşdeğeri
Yönetici	Üyesi Project Administrators
Yaz	Üyesi Contributors
Oku	Üyesi Readers

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üvenlik'i seçin.
4. Belirli bir kullanıcı, ekip veya grup eklemek ve işlem hattı izinlerini özelleştirmek için Ekle... öğesini seç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 depoya depo adı self verilir. Varsayılan olarak bu, işlem hattınızın oluşturduğu depodur.

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

Klasik

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

Authentication type	İşlem hatları kullanılarak çalıştırılır	GitHub Denetimleri ile çalışır
1. GitHub Uygulaması	Azure Pipelines kimliği	Yes
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 Denetimleriyle birlikte çalışarak GitHub'da derleme, test ve kod kapsamı sonuçlarını görüntüler.

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ından yü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. Tüm depolar için uygulamayı yüklemeye alternatif olarak, depo yöneticileri tek tek depolar için uygulamayı birer birer yükleyebilir. Bu, yöneticiler için daha fazla çalışma gerektirir, ancak hiçbir avantajı veya dezavantajı yoktur.

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 depo, 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 depolar için kullanmaya 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'u kullanmak için, işlem hattı oluştururken depo listesinin altında Farklı bir bağlantı seçin'i 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 depo, 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 işlem İşlem Hatları > Hizmet bağlantıları Yeni hizmet bağlantısı >> GitHub > Yetkilendirmesi altındaki Azure DevOps proje ayarlarında yapılabilir. Azure Pipelines'a buradaki "İzinler" altında depolarınıza erişim izni verin.

• 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 işlem İşlem Hatları > Hizmet bağlantıları Yeni hizmet bağlantısı >> GitHub > Yetkilendirmesi altındaki Azure DevOps proje ayarlarında yapılabilir. Diğer kişinin buradaki "İzinler" altındaki depolarına Azure Pipelines erişimi 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 işlem İşlem Hatları > Hizmet bağlantıları Yeni hizmet bağlantısı >> GitHub > Yetkilendirmesi altındaki Azure DevOps proje ayarlarında yapılabilir. Burada "Kuruluş erişimi" altında kuruluşunuza Azure Pipelines erişimi verin. 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 işlem İşlem Hatları > Hizmet bağlantıları Yeni hizmet bağlantısı >> GitHub > Yetkilendirmesi altındaki Azure DevOps proje ayarlarında yapılabilir. Kuruluş sahibinin burada "Kuruluş erişimi" altında Kuruluşa Azure Pipelines erişimi vermesi gerekir. 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 kullanmak üzere yetkilendirdikten sonra, daha sonra iptal etmek ve daha fazla kullanımı önlemek için GitHub ayarlarınızda OAuth Uygulamaları'nı ziyaret edin. Azure DevOps proje ayarlarınızdaki GitHub hizmet bağlantıları listesinden de silebilirsiniz.

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

PAT'ler 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'ni ziyaret edin. Gerekli izinler , admin:repo_hook, read:userve user:email'tirrepo. 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ına 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 depo, 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'nin Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: repo, admin:repo_hook, read:userve user:email.

• Depo başka birinin kişisel GitHub hesabındaysa, PAT'nin Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: 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'nin Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: 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'nin Kişisel erişim belirteçleri altında gerekli erişim kapsamlarına sahip olması gerekir: 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. 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çleri'ni ziyaret edin. Azure DevOps proje ayarlarınızdaki 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'de tanıtılan Örtük YAML CI tetikleyicisini devre dışı bırak ayarı etkinleştirilmediği sürece YAML işlem hatları varsayılan olarak tüm dallarda ci tetikleyicisi ile yapılandırılır. Zımni YAML CI tetikleyicisini devre dışı bırak ayarı kuruluş düzeyinde veya proje düzeyinde yapılandırılabilir. Örtük YAML CI tetikleyicisini devre dışı bırak ayarı etkinleştirildiğinde, YAML işlem hattının bir trigger bölümü yoksa YAML işlem hatları için CI tetikleyicileri etkinleştirilmez. Varsayılan olarak, Örtük YAML CI tetikleyicisini devre dışı bırak etkin değildir.

Dallar

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

trigger:
- main
- releases/*

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

Not

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

Not

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

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

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

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

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

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

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

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

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

Önemli

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

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

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

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

Not

batch depo kaynak tetikleyicilerinde desteklenmez.

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

Not

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

Yollar

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

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

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

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

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

Etiketler

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

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

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

Önemli

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

CI'yi geri çevirme

CI tetikleyicisini devre dışı bırakma

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

# A pipeline with no CI trigger
trigger: none

Önemli

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

Klasik

Derlemenin kodu her iade etmesinde çalıştırılmasını istiyorsanız, Tetikleyiciler sekmesinde Sürekli tümleştirmeyi etkinleştir'i seçerek 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 ,araçları dışlarsanız /tools/trigger-runs-on-these ekleyebilirsiniz
• Yol filtrelerinin sırası önemli değildir.
• Git'teki yollar büyük/küçük harfe duyarlıdır. Gerçek klasörlerle aynı durumu kullandığınızdan emin olun.

Örnek

Örneğin, derlemenizin özellik dallarınızdaki main değişiklikler tarafından tetiklenmesini ancak tümünün tetiklenmemesini istersiniz. 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 dahil [skip ci] edin; Azure Pipelines bu gönderim için CI çalıştırmayı atlar. Aşağıdaki çeşitlemelerden herhangi birini de kullanabilirsiniz.

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

Koşullarda tetikleyici türünü kullanma

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

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

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

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

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

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

Joker karakterler

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

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

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Çekme isteği tetikleyicileri

Çekme isteği (PR) tetikleyicileri, 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

Dallar

Çekme isteklerinizi doğrularken hedef dalları belirtebilirsiniz. Örneğin, ve releases/*hedeflerini main hedefleyen çekme isteklerini doğrulamak için aşağıdaki pr tetikleyiciyi 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 tetikledikten sonra) tetikleyicilerde değişkenleri kullanamazsınız.

Not

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

GitHub, çekme isteği oluşturulduğunda yeni bir başvuru oluşturur. Başvuru, çekme isteğinin kaynak ve hedef dalları arasındaki birleştirilmiş kod olan birleştirme işlemesine işaret eder. Çekme isteği doğrulama işlem hattı, bu başvurunun işaret olduğu 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 tetikleyici görünmüyorsa, aşağıdaki pr tetikleyiciyi 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ümesine sahip bir pr tetikleyici belirttiğinizde, işlem hattı yalnızca bu dallara güncelleştirmeler 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 hedefin main veya releases/* dalın releases/old* dışlandığı doğrulanır.

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

Yollar

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

# 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 . Derleme atlandığında GitHub'a nötr durum gönderme.
• Joker karakterler artık yol filtreleri ile destekleniyor.
• Yollar her zaman deponun köküne göre belirtilir.
• Yol filtreleri ayarlamazsanız, deponun kök klasörü varsayılan olarak örtük olarak eklenir.
• Bir yolu dışlarsanız, daha derin bir klasöre nitelemediğiniz sürece bu yolu da ekleyemezsiniz. Örneğin ,araçları dışlarsanız /tools/trigger-runs-on-these ekleyebilirsiniz
• Yol filtrelerinin sırası önemli değildir.
• Git'teki yollar büyük/küçük harfe duyarlıdır. Gerçek klasörlerle aynı durumu kullandığınızdan emin olun.
• Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetikledikten sonra) yollarda değişkenleri kullanamazsınız.
• 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 istekleri için çekme isteği tetikleyicilerini devre dışı bırakmak için özelliğini olarak falseayarlayındrafts.

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

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

# no PR triggers
pr: none

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

Not

Tetikleyiciniz pr tetiklenmiyorsa SSS bölümündeki sorun giderme adımlarını izleyin.

Klasik

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

Dahil etmek ve dışlamak için dallar belirtebilirsiniz. Açılan menüden bir dal adı seçin ve uygun şekilde Ekle veya Dışla'yı seçin. 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ı (veya değişkenlerinden herhangi birini) içeren [skip ci] gönderilen işlemeler olup olmadığına bakılmaksızın birleştirme işlemesinde (çekme isteğinin kaynak ve hedef dalları arasındaki birleştirilmiş kod) çalıştırılır.
• İletileri veya açıklamaları (veya değişkenlerinden herhangi birini) içeren [skip ci] gönderilen işlemeler yoksa, çekme isteğinin kaynak dalında yapılan değişikliklerle tetiklenen işlem hatları. En az bir gönderilen işleme içeriyorsa [skip ci], işlem hatları çalışmaz.

Son olarak, çekme isteğini birleştirdikten sonra, birleştirme işlemesinin iletisi veya açıklaması (veya değişkenlerinden herhangi birini) içermiyorsa [skip ci] , 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, deponun ayarlarında korumalı dalları yapılandırmak için GitHub'ın belgelerini izleyin.

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

   

Ö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 kaynak, Azure DevOps projenizi herkese açık hale getirerek işlem hattınızın derleme sonuçlarını, günlüklerini ve test sonuçlarını oturum açmadan herkesin görüntülemesini sağlayabilirsiniz. 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
• Önemli güvenlik konuları

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 diziler: 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 gelen 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 paketleri: İş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ı'yı seçin, işlem hattınızı bulun ve Düzenle'yi seçin.
2. Tetikleyiciler sekmesini seçin. Çekme isteği tetikleyicisini etkinleştirdikten sonra Bu deponun ç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 olarak işaretlenmiş değişkenler oluşturma

GitHub işlem hatlarında bu önlemi atlamak için Gizli dizileri çatal derlemelerinde 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 derlemelerle aynı izinlere sahip olmasını sağlayın ayarını etkinleştirin.

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

Çatallanmış GitHub depolarından çekme isteklerini derlemeyi sınırla denetimini 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. Şunları yapmayı 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 229'dan başlayarak işlem hatlarınızın güvenliğini artırmak 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 ayarıdır.

Çatallanmış depolardan çekme isteklerini güvenli bir şekilde derleyin seçeneğini belirlediğinizde, tüm işlem hatları, kuruluş veya proje genelinde, gizli dizileri çatallanmış depolardaki PR'lerin derlemelerinde kullanılabilir hale getiremez, bu derlemelerin normal derlemelerle aynı izinlere sahip olmasını sağlayamaz 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 vermemeye 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 veya bunları güvenli bir şekilde derlemesine izin vermemeye 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 varsayılan olarak çatallanmış depolardan güvenli bir şekilde çekme istekleri derlemektedir.

Ö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 genelse veya güvenilmeyen kullanıcılar derlemeleri otomatik olarak tetikleyen çekme istekleri gönderebiliyorsa, bu riski azaltmak için Gizli dizileri çatal derlemelerinde 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 bir 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 olmadığı ve çekme isteği oluşturucularına güvenmediğiniz sürece gizli dizileri depolamayın veya gizli dizileri kullanan diğer derlemeleri ve sürümleri aynı aracıda gerçekleştirin.

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, Tetikleyiciler'i seçin. Ardından çekme isteği doğrulaması altında, çekme isteği oluşturmadan önce Ekip üyesinin açıklamasını gerektir'i etkinleştirin.
   • Çekme isteği oluşturmadan önce bir ekip üyesinin açıklamasını istemek için Tüm çekme isteklerinde'yi 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 bir üye tarafından çekme isteği yapıldığında ekip üyesinin açıklamasını gerektirmek için Yalnızca ekip üyesi olmayanlardan gelen çekme isteklerinde'yi seçin. Bu iş akışında, bir ekip üyesinin bir derlemeyi tetikleyebilmek için ikincil bir ekip üyesinin incelemesine ihtiyacı yoktur.

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

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

Command	Result
/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 yerine kullanarak /azp/AzurePipelinesyorum yapabilirsiniz.

Önemli

Bu komutlara verilen yanıtlar çekme isteği tartışmasında yalnızca işlem hattınız Azure Pipelines GitHub Uygulamasını kullanı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 herkese açık olduğundan emin olun veya kendinizi doğrudan bir depo işbirliği üyesi 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 (öğesini kuruluşunuzun adıyla değiştirin Your-Organization ): 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 şudur: 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.

Kullanıma Al

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

Not

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

Tercih edilen Git sürümü

Windows aracısı kendi Git kopyasıyla birlikte gelir. Dahil edilen kopyayı kullanmak yerine kendi Git'inizi sağlamayı tercih ediyorsanız olarak ayarlayın System.PreferGitFromPathtrue. 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 adlı sbir dizinde kullanıma alınır. YAML işlem hatları için, ile pathbelirterek checkout bunu değiştirebilirsiniz. Belirtilen yol ile $(Agent.BuildDirectory)görelidir. Örneğin: kullanıma alma yolu değeri mycustompath ve $(Agent.BuildDirectory) ise C:\agent\_work\1, kaynak kodu içine C:\agent\_work\1\mycustompathkullanıma alınır.

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

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

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

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

Klasik

Bu ayar klasik düzenleyicide yapılandırılamaz. Kaynak kodunuz ile ilgili $(Agent.BuildDirectory)olarak adlı sbir dizinde kullanıma alınır. Örneğin: ise $(Agent.BuildDirectory)C:\agent\_work\1, kaynak kodu içine C:\agent\_work\1\mycustompathiade edilir.

Alt modüller

YAML

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

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

Klasik

Alt modüllerden dosya indirmek istiyorsanız, alt modüller ayarını işlem hattınızdaki Kaynakları al görevinin özelliklerinden yapılandırabilirsiniz.

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

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

• Kimlik doğrulaması:

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

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

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

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

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

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

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

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

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

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

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

Not

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

Etiketleri eşitleme

Önemli

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

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

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

YAML

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

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

steps:
- checkout: self
  fetchTags: true

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

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

   

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

   

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

   

Not

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

Klasik

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

Varsayılan davranış

• Eylül 2022'de yayımlanan Azure DevOps sprint 209 sürümünden önce oluşturulan mevcut işlem hatları için, etiketleri eşitlemek için varsayılan değer, Etiketleri eşitleme seçenekleri eklenmeden önceki mevcut davranışla aynı kalır.true
• 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ğerdir false.

Not

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

Sığ getirme

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

Önemli

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

YAML

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

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

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

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

   

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

   

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

   

Not

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

Klasik

İşlem hattınızdaki Kaynakları al görevinin özelliklerinden Sığ getirme ayarını 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 Kaynakları eşitleme ayarını ayarlayarak checkout: noneyapılandırabilirsiniz.

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

Klasik

İş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, derlemek için kullandığınız görev veya aracın Herhangi bir Temiz seçeneğini devre dışı bırakarak artımlı olarak oluşturduğunuzdan emin olun.

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

Not

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

YAML

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

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

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

git clean -ffdx
git reset --hard HEAD

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

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

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

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

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

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

Klasik

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

• Kaynaklar: Derleme işlem hattı içindeki $(Build.SourcesDirectory)değişiklikleri geri alır. Daha açık belirtmek gerekirse, aşağıdaki Git komutları kaynağı getirmeden önce yürütülür.

  git clean -ffdx
  git reset --hard HEAD
  

• Kaynaklar ve çıkış dizini: Yukarıdaki Kaynaklar seçeneğiyle aynı işlem, artı olarak: siler ve yeniden oluşturur$(Build.BinariesDirectory). ve $(Common.TestResultsDirectory) değerlerinin $(Build.ArtifactStagingDirectory) bu ayarlardan herhangi biri ne olursa olsun her derlemeden önce silindiğini ve yeniden oluşturduğunu unutmayın.

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

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

Etiket kaynakları

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

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

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

Klasik

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

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

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

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

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

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

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

Ö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/PR'ye geri postalanır. Bu tür güncelleştirmeleri göndermek için GitHub durum API'si 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 burada bulabilirsiniz.

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

• 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.
• İşlem hattında genişletilen ve dahil edilen şablonların kullanılması, 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 en fazla 2000 dalı Azure Devops Portalı'ndaki açılan listelere yükler. Örneğin, el ile ve zamanlanmış derlemeler için Varsayılan dal ayarına veya işlem hattını el ile çalıştırırken dal seçerken. listede istediğiniz dalı görmüyorsanız, istediğiniz dal adını el ile yazın.

SSS

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

• Bağlan ion türleri: İş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 oluyor: İşlem hattım tetikleniyor, ancak kullanıma alma adımında başarısız oluyor.
• Yanlış sürüm: İşlem hattım çalışıyor, ancak kaynak/YAML'nin beklenmeyen bir sürümünü kullanıyor.
• Eksik durum güncelleştirmeleri: Azure Pipelines durum güncelleştirmesi bildirmediğinden GitHub PR'lerim 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'i seçin. Ardından YAML sekmesini ve ardından Kaynakları al adımını seçin. Bağlantı kullanılarak yetkilendirilen bir başlık görürsünüz: İşlem hattını GitHub ile tümleştirmek için kullanılan hizmet bağlantısını belirtir. 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 yaparım??

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

  

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

  

• İş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ğlan ion 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, adresine gidin https://github.com/<org_name>/<repo_name>/settings/installations 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ğlan ion 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 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. Tetikleyiciler menüsüne gidin.
3. Buradan YAML sürekli Tümleştirme tetikleyicisini geçersiz kıl'ı seçin.
4. Tetikleyici için eklenecek veya hariç tutulacak dalları belirtin.

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

Teslim alma başarısız oluyor

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

remote: 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. Bunun nedeni nedir?

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

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ış tetikleyiciler
• İşlem hattını tamamlama tetikleyicileri