Depolama GitHub oluşturma

Azure Pipelines

Azure Pipelines her çekme isteğini otomatik olarak derleme ve doğrulama ve GitHub işleme. Bu makalede, GitHub ile Azure Pipelines.

GitHub ile Azure Pipelines tümleştirmesine yeni başladıysanız, GitHub deposuyla çalışan ilk işlem hattınızı almak için ilk işlem hattınızı oluşturma adımlarını izleyin ve 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önebilirsiniz.

Kuruluşlar ve kullanıcılar

GitHub ve Azure Pipelines birlikte iyi tümleştiren iki bağımsız hizmettir. Her biri kendi kuruluşu ve kullanıcı yönetimine sahip. Bu bölümde, kuruluşun ve kullanıcıların kuruluştan GitHub çoğaltma Azure Pipelines.

Kuruluşlar

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

GitHub yapısı

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

Azure DevOps yapısı

Azure DevOps, şu GitHub yansıtıcı olabilir:

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

GitHub eşlenmiş Azure DevOps

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

  1. Kendi Azure DevOps veya kullanıcı hesabınızla GitHub bir kuruluş oluşturun. gibi bir URL'si https://dev.azure.com/your-organization olacak.
  2. Kuruluşta Azure DevOps adlı projeler oluşturun. Gibi URL'lere sahip https://dev.azure.com/your-organization/your-repository olur.
  3. Bu Azure DevOps Project, kuruluşa ve oluşturdukları depoya GitHub adlı işlem hatları your-organization.your-repository oluşturun. Ardından, hangi depolar için olduklarını net bir şekilde ifade etmektir.

Bu düzenin ardından, GitHub depolar ve Azure DevOps Projeleriniz eşleşen URL yollara sahip olur. Örnek:

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

Kullanıcılar

GitHub kullanıcılarınız otomatik olarak Azure Pipelines. Azure Pipelines kimlikleri GitHub değildir. Bu nedenle, Azure Pipelines kimliğini ve e-posta adreslerini kullanarak kullanıcılara bir derleme hatası veya bir PR doğrulama hatasının otomatik olarak bildir GitHub yolu yoktur. Yeni kullanıcıları çoğaltmak için Azure Pipelines açıkça GitHub gerekir. Yeni kullanıcılar oluşturdukta, kullanıcıların izinlerini Azure DevOps yansıtacak şekilde yapılandırabilirsiniz GitHub. Ayrıca, bildirim bildirimlerini Azure DevOps kimliklerini kullanarak Azure DevOps yapılandırsınız.

GitHub rollerini

GitHub üye rolleri (değiştir) https://github.com/orgs/your-organization/people içinde your-organization bulunur.

Azure DevOps üye izinleri (değiştir) https://dev.azure.com/your-organization/_settings/security içinde your-organization bulunur.

Bir kuruluşta GitHub ve bir kuruluşta Azure DevOps roller aşağıda gösterilmiştir.

GitHub kuruluş rolü Azure DevOps eşdeğer kuruluş
Sahip Üyesi Project Collection Administrators
Faturalama yöneticisi Üyesi Project Collection Administrators
Üye üyesi. Project Collection Valid Users Varsayılan olarak, bu grubun yeni projeler oluşturma izni yok. Bunu değiştirmek için grubun iznini Create new projects olarak ayarlayın veya ihtiyacınız olan Allow izinlere sahip yeni bir grup oluşturun.

GitHub hesabı rollerini atama

Bir GitHub hesabı, hesabın sahibi olan tek bir role sahip olur.

Azure DevOps üye izinleri (değiştir) https://dev.azure.com/your-organization/_settings/security içinde your-organization bulunur.

Kullanıcı GitHub rolü, kuruluş izinlerine Azure DevOps şekilde eşler.

GitHub hesabı rolü Azure DevOps eşdeğer kuruluş
Sahip Üyesi Project Collection Administrators

GitHub izinlerini ayarlama

GitHub izinleri (ve yerine) https://github.com/your-organization/your-repository/settings/collaboration içinde your-organizationyour-repository bulunur.

Azure DevOps izinlerine (ve yerine) https://dev.azure.com/your-organization/your-project/_settings/securityyour-organization yer your-project alır.

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

GitHub iznini kullanma Azure DevOps eşdeğer proje
Yönetici Üyesi Project Administrators
Yazma Üyesi Contributors
Okuma Üyesi Readers

Depo GitHub takımlara izin verdiyse, proje ayarlarınız için eşleşen Teams Azure DevOps oluşturabilirsiniz. Ardından, aynı kullanıcılar gibi ekipleri yukarıdaki güvenlik gruplarına ekleyin.

İşlem hattına özgü izinler

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

  1. Projenin Pipelines sayfasını ziyaret edin https://dev.azure.com/your-organization/your-project/_build (örneğin).
  2. Belirli izinlerin ayarlan olduğu işlem hattını seçin.
  3. ' ... 'bağlammenüsünde Güvenlik'i seçin.
  4. Belirli bir kullanıcı, ekip veya grup eklemek ve işlem hattı için izinlerini özelleştirmek için Ekle... 'ye tıklayın.

Depolara GitHub erişme

Yeni bir işlem hattı oluşturmak için önce bir GitHub ve ardından bu depoda bir YAML dosyası seçersiniz. YAML dosyasının mevcut olduğu depoya depo self denir. Varsayılan olarak bu, işlem hattınızı derlemek için depoyu kullanır.

Daha sonra işlem hattınızı farklı bir depoyu veya birden çok depoyu kontrol etmek üzere yapılandırabilirsiniz. Bunun nasıl olduğunu öğrenmek için bkz. çoklu repo alma.

Azure Pipelines tetiklemek ve derlemeler sırasında bunların kodunu getirmek için depolarnıza erişim izni verilmesi gerekir.

İşlem hattı oluştururken depolama depolarınıza Azure Pipelines için 3 GitHub kimlik doğrulaması türü vardır.

Kimlik doğrulaması türü Pipelines çalıştır GitHub Denetimleri ile çalışır
1. GitHub Uygulama Azure Pipelines kimliği Yes
2. OAuth Kişisel GitHub kimliğiniz No
3. Kişisel erişim belirteci (PAT) Kişisel GitHub kimliğiniz No

GitHub kimlik doğrulaması

Azure Pipelines GitHub Uygulaması, sürekli tümleştirme işlem hatları için önerilen kimlik doğrulaması t t.1. GitHub Uygulamasını GitHub hesabınıza veya GitHub yükleyerek, işlem hattınız kişisel kimlik bilgilerinizi GitHub çalıştırabilirsiniz. Derlemeler ve GitHub durum güncelleştirmeleri, Azure Pipelines kullanılarak gerçekleştirilir. Uygulama derleme, test GitHub kod kapsamı sonuçlarını görüntülemek için GitHub Denetimler ile birlikte GitHub.

GitHub App'i kullanmak için, depoların bir GitHub veya tüm depolarının kullanıcı hesabına yükleyin. GitHub Uygulaması, uygulamanın giriş sayfasından yük devredebilirsiniz.

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

GitHub kuruluşunda tüm depolar için GitHub Uygulamasını yüklürseniz, toplu e-Azure Pipelines gönderme veya sizin adına işlem hatlarını otomatik olarak ayarlama konusunda endişelenmenize gerek yok. Depo yöneticileri uygulamayı tüm depolar için yüklemeye alternatif olarak tek tek depolar için tek tek yükleyebilir. Bunun için yöneticiler için daha fazla çalışma gerekir ancak bunun hiçbir avantajı veya dezavantajı yoktur.

GitHub'de gereken izinler

Azure Pipelines GitHub yüklemesi, kuruluş sahibi GitHub depo yöneticisi olarak çalışmanı gerektirir. Ayrıca, sürekli tümleştirme ve çekme isteği tetikleyicileriyle GitHub bir depolama deposu için işlem hattı oluşturmak için gerekli GitHub izinlerine sahipsiniz. Aksi takdirde, işlem hattı oluşturulurken depo depo listesinde görünmez. Deponun kimlik doğrulaması türüne ve sahipliğine bağlı olarak, uygun erişimin yapılandırıldığından emin olma.

  • Hesap kişisel hesap GitHub ise, Azure Pipelines GitHub App'i kişisel GitHub yükleyin. İşlem hattını Azure Pipelines.

  • Hesap başka birinin kişisel hesap GitHub ise, diğer kişinin Azure Pipelines GitHub App'i kendi kişisel GitHub yüklemesi gerekir. Deponun ayarlarında "Ortak Çalışanlar" altında ortak çalışan olarak eklenmeniz gerekir. Size e-posta ile gönderilen bağlantıyı kullanarak daveti ortak çalışan olarak kabul edin. Bunu yaptıktan sonra, bu depo için bir işlem hattı oluşturabilirsiniz.

  • Repo, sahip GitHub bir kuruluşta ise, Azure Pipelines GitHub App'i GitHub yükleyin. Deponun ayarlarında "Ortak çalışanlar ve takımlar" altında ortak çalışan olarak da eklenmeli veya takımınız eklenmiştir.

  • Depo başka birinin sahip olduğu GitHub kuruluşta ise, GitHub kuruluş sahibi veya depo yöneticisinin Azure Pipelines GitHub Uygulamasını kuruluşa yüklemesi gerekir. Deponun ayarlarında "Ortak çalışanlar ve takımlar" altında ortak çalışan olarak eklenmeniz veya takımınız eklenmeli. Size e-posta ile gönderilen bağlantıyı kullanarak daveti ortak çalışan olarak kabul edin.

GitHub uygulama izinleri

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

İzin Bu Azure Pipelines ne yapar?
Koda yazma erişimi Yalnızca bilinçli eyleminiz üzerine Azure Pipelines, bir YAML dosyasını depo deponun seçili bir dalına işerek işlem hattı GitHub basitleştirir.
Meta verilere okuma erişimi Azure Pipelines, GitHub özette bir derlemeyle ilişkili depoyu, dalları ve sorunları görüntülemek için meta verileri alır.
Denetimlere okuma ve yazma erişimi Azure Pipelines kendi derlemesini, testini ve kod kapsamı sonuçlarını okuyacak ve yazacak ve bu sonuçların GitHub.
Çekme isteklerine okuma ve yazma erişimi Yalnızca bilinçli eyleminiz Azure Pipelines, Azure Pipelines deponun seçili dallarından biri için kaydedilmiş bir YAML dosyası için çekme isteği oluşturarak işlem hattı oluşturmayı GitHub sağlar. Azure Pipelines, çekme istekleriyle ilişkili derleme özetlerinde görüntülemek için çekme isteği meta verilerini alır.

Uygulama GitHub sorunlarını giderme

GitHub gibi bir hata görüntüleniyor olabilir:

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

Bu, GitHub App'in büyük olasılıkla zaten sizin için yüklü olduğu anlamına gelir. Kuruluşta bir depo için işlem hattı sanız, GitHub App otomatik olarak GitHub.

Birden çok kuruluşta ve Azure DevOps işlem hattı oluşturma

GitHub Uygulaması yüklendikten sonra, kuruluşun farklı kuruluş ve projelerinde yer alan depoları Azure DevOps işlem hatları oluşturulabilir. Ancak, birden çok Azure DevOps kuruluşunda tek bir depo için işlem hatları oluşturmanız, yalnızca ilk kuruluşun işlem hatlarının işlemeler veya çekme istekleri GitHub otomatik olarak tetiklenir. İkincil veya zamanlanmış derlemeler, ikincil Azure DevOps mümkündür.

OAuth kimlik doğrulaması

OAuth, kişisel hesap hesabınızla depolar için çalışmaya başlamanın en basit GitHub t t'dır. GitHub durum güncelleştirmeleri kişisel kimlik bilgileriniz adına GitHub yapılır. İşlem hatlarının çalışmaya devam etmek için depo erişiminizin etkin kalması gerekir. Denetimler GitHub bazı özellikler OAuth ile kullanılamaz ve GitHub gerektirir.

OAuth'u kullanmak için işlem hattı oluştururken depo listesinin altında farklı bir bağlantı seçin'e tıklayın. Ardından, OAuth ile oturum GitHub yetkilendirmek için Yetkilendir'e tıklayın. Daha sonra kullanmak üzere bir OAuth Azure DevOps projenize kaydedilir ve oluşturulan işlem hattında kullanılır.

GitHub'de gereken izinler

Sürekli tümleştirme ve çekme isteği tetikleyicileriyle GitHub bir depo için işlem hattı oluşturmak için, gerekli GitHub izinlerine sahipsiniz. Aksi takdirde, işlem hattı oluşturulurken depo depo listesinde görünmez. Deponun kimlik doğrulaması türüne ve sahipliğine bağlı olarak, uygun erişimin yapılandırıldığından emin olma.

  • Depo kişisel hesap hesap GitHub en az bir kez, kişisel hesap kimlik bilgilerinizi kullanarak OAuth GitHub kimlik doğrulaması GitHub olun. Bu, Hizmet bağlantıları Azure DevOps Yeni hizmet bağlantısı Pipelines Yetkilendir altında >> proje ayarlarında GitHub >> yapılabilir. Burada Azure Pipelines "İzinler" altında depolara erişim izni verin.

  • Depo başka birinin kişisel hesap GitHub, en az bir kez, diğer kişinin kişisel hesap kimlik bilgilerini kullanarak OAuth GitHub kimlik doğrulaması GitHub gerekir. Bu, Hizmet bağlantıları Azure DevOps Yeni hizmet bağlantısı Pipelines Yetkilendir altında >> proje ayarlarında GitHub >> yapılabilir. Diğer kişinin buradaki "Azure Pipelines" altında depolarına erişim izni ve ver versin. Deponun ayarlarında "Ortak Çalışanlar" altında ortak çalışan olarak eklenmeniz gerekir. Size e-posta ile gönderilen bağlantıyı kullanarak daveti ortak çalışan olarak kabul edin.

  • Depo, sahip GitHub kuruluşta ise, en az bir kez, kişisel hesap kimlik bilgilerinizi kullanarak OAuth GitHub kimlik doğrulaması GitHub olun. Bu, Hizmet bağlantıları Azure DevOps Yeni hizmet bağlantısı Pipelines Yetkilendir altında >> proje ayarlarında GitHub >> yapılabilir. Burada Azure Pipelines "Kuruluş erişimi" altında, bu kuruluşa erişim izni vermek. Deponun ayarlarında "Ortak çalışanlar ve takımlar" altında ortak çalışan olarak eklenmeniz veya takımınız eklenmeli.

  • Depo en az bir GitHub sahip olduğu bir kuruluşta ise, GitHub kuruluş sahibinin kişisel hesap kimlik bilgilerini kullanarak OAuth ile GitHub kimlik doğrulaması GitHub gerekir. Bu, Hizmet bağlantıları Azure DevOps Yeni hizmet bağlantısı Pipelines Yetkilendir altında >> proje ayarlarında GitHub >> yapılabilir. Kuruluş sahibi, buradaki "Azure Pipelines" altında kuruluşa erişim izni versin. Deponun ayarlarında "Ortak çalışanlar ve takımlar" altında ortak çalışan olarak eklenmeniz veya takımınız eklenmeli. Size e-posta ile gönderilen bağlantıyı kullanarak daveti ortak çalışan olarak kabul edin.

OAuth erişimini iptal etme

OAuth kullanmak Azure Pipelines yetkilendirmenin ardından, daha sonra iptal etmek ve daha fazla kullanımı önlemek için OAuth Uygulamaları'GitHub ziyaret edin. Ayrıca, bunu proje ayarlarınıza bağlı GitHub bağlantıları listesinden Azure DevOps silebilirsiniz.

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

PAT'ler OAuth ile etkili bir şekilde aynıdır, ancak bu kimlik doğrulamasına hangi izinlerin Azure Pipelines. Derlemeler GitHub durum güncelleştirmeleri kişisel kimlik bilgileriniz adına GitHub gerçekleştirilir. Derlemelerin çalışmaya devam etmek için depo erişiminizin etkin kalması gerekir.

PAT oluşturmak için kişisel erişim belirteçleri'ne gidin ve GitHub edin. Gerekli izinler repo : , , ve admin:repo_hookread:useruser:email . Bunlar yukarıda OAuth kullanırken gereken izinlerin aynılarıdır. Oluşturulan PAT'i panoya kopyalayın ve proje ayarlarınıza yeni bir GitHub hizmet Azure DevOps yapıştırın. Daha sonra hatırlayacak olursanız hizmet bağlantısını kullanıcı adınızın GitHub olun. İşlem hattı oluştururken daha sonra Azure DevOps projeniz içinde kullanılabilir.

GitHub'de gereken izinler

Sürekli tümleştirme ve çekme isteği tetikleyicileriyle GitHub bir depo için işlem hattı oluşturmak için, gerekli GitHub izinlerine sahipsiniz. Aksi takdirde, işlem hattı oluşturulurken depo depo listesinde görünmez. Deponun kimlik doğrulaması türüne ve sahipliğine bağlı olarak, aşağıdaki erişimin yapılandırıldığından emin olma.

  • depo, kişisel GitHub hesabınızda ise, PAT, kişisel erişim belirteçlerialtında gerekli erişim kapsamlarına sahip olmalıdır: ,, admin:repo_hookread:user ve user:email .

  • depo, başka birinin kişisel GitHub hesablardayken, PAT kişisel erişim belirteçlerialtında gerekli erişim kapsamlarına sahip olmalıdır: ,, admin:repo_hookread:user ve user:email . "Ortak çalışanlar" altındaki deponun ayarlarına ortak çalışan olarak eklenmeli. Size e-posta ile gönderilen bağlantıyı kullanarak ortak çalışan olan daveti kabul edin.

  • depo sahip olduğunuz bir GitHub kuruluşlardayken PAT, kişisel erişim belirteçlerialtında gerekli erişim kapsamlarına sahip olmalıdır: ,, admin:repo_hookread:user ve user:email . Ortak çalışan olarak eklenmeli veya takımınızın "ortak çalışanlar ve takımlar" altındaki deponun ayarlarına eklenmesi gerekir.

  • depo, başka birinin sahip olduğu bir GitHub kuruluşlardayken PAT, kişisel erişim belirteçlerialtında gerekli erişim kapsamlarına sahip olmalıdır: ,, admin:repo_hookread:user ve user:email . Ortak çalışan olarak eklenmeli veya takımınızın "ortak çalışanlar ve takımlar" altındaki deponun ayarlarına eklenmesi gerekir. Size e-posta ile gönderilen bağlantıyı kullanarak ortak çalışan olan daveti kabul edin.

PAT erişimini iptal et

bir PAT kullanmak için Azure Pipelines doğruladıktan sonra, daha sonra silmek ve daha fazla kullanımı engellemek için GitHub ayarlarınızda kişisel erişim belirteçlerini ziyaret edin. ayrıca, Azure DevOps proje ayarlarınızda GitHub hizmet bağlantıları listesinden da silebilirsiniz.

CI Tetikleyicileri

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

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

Dallar

Hangi dalların bir basit sözdizimi ile CI Tetikleyicileri almasını denetleyebilirsiniz:

trigger:
- master
- releases/*

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

Not

Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetiklendikten sonra), Tetikleyiciler içinde değişkenler kullanamazsınız.

Not

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

Veya kullanan daha karmaşık Tetikleyiciler için excludebatch , aşağıdaki örnekte gösterildiği gibi tam sözdizimini kullanmanız gerekir.

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

Yukarıdaki örnekte, bir değişiklik ana veya herhangi bir yayınlar dalına itiliyorsa işlem hattı tetiklenir. Ancak, ile başlayan bir yayınlar dalında değişiklik yapılırsa tetiklenmez old .

Yan tümce içermeyen bir exclude yan tümce belirtirseniz include , yan tümcesinde belirtmeye eşdeğerdir *include .

Listelerde dal adlarını belirtmenin yanı sıra branches , aşağıdaki biçimi kullanarak, etiketleri temel alan Tetikleyicileri de yapılandırabilirsiniz:

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

Herhangi bir tetikleyici belirtmezseniz, varsayılan olarak şunu yazmış olursunuz:

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 dahil olmak üzere açıkça yapılandırılmış dallara yapılan bildirimler bir işlem hattı tetikler. Ekler önce işlenir ve sonra bu listeden kaldırılır.

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

Değişiklikleri sık karşıya yüklerken çok sayıda ekip üyesine sahipseniz, başlattığınız çalıştırmaların sayısını azaltmak isteyebilirsiniz. batchOlarak ayarlarsanız true , işlem hattı çalışırken sistem, çalıştırma tamamlanana kadar bekler ve ardından henüz derlenmemiş olan tüm değişikliklerle başka bir çalıştırma başlatır.

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

Bu örneği açıklığa kavuşturmak için, ana bir gönderinin A Yukarıdaki işlem hattının çalışmasına neden olduğunu söylememizi sağlar. İşlem hattı çalışırken, depoya ek bildirimler B ve C meydana gelir. Bu güncelleştirmeler hemen yeni bağımsız çalıştırmalar başlatmazlar. Ancak, ilk çalıştırma tamamlandıktan sonra, o zamana kadar tüm bildirimler birlikte oluşturulur ve yeni bir çalıştırma başlatılır.

Not

İşlem hattının birden çok işi ve aşaması varsa, ilk çalıştırma, ikinci çalıştırma başlamadan önce tüm işlerini ve aşamalarını tamamlayarak veya atlayarak bir Terminal durumuna ulaşmalıdır. Bu nedenle, birden çok aşama veya onay içeren bir ardışık düzende bu özelliği kullanırken dikkatli olmanız gerekir. Bu tür durumlarda derlemelerinizi toplu yapmak istiyorsanız, CI/CD işleminizi derleme için bir tane olmak üzere iki işlem hattına bölmeniz önerilir (toplu işleme ile) ve diğeri dağıtımlar için.

Yollar

Dahil etmek veya hariç tutmak için dosya yolları belirtebilirsiniz.

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

Yolları belirttiğinizde, doğrudan tetiklenecek dalları belirtmeniz gerekir. Bir işlem hattını yalnızca bir yol filtresiyle tetikleyemez; 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.

İpuçları:

  • Yollar her zaman deponun köküne göre belirtilir.
  • Yol filtrelerini ayarlamazsanız, deponun kök klasörü varsayılan olarak örtülü olarak dahil edilir.
  • Bir yolu dışladığınızda, daha derin bir klasöre niteetmediğiniz müddetçe da dahil edilemez. Örneğin, /Tools dışlandıysanız, /Tools/Trigger-runs-on-bu işlemleri dahil edebilirsiniz.
  • Yol filtrelerinin sırası ne kadar önemlidir.
  • 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 (tetikleyici başlatıldıktan sonra) değerlendirildiğinden, yollarda değişkenler kullanamazsınız.

Etiketler

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

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

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

Önemli

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

CI 'yı kapatma

CI tetikleyicisini devre dışı bırakma

' İ belirterek CI tetikleyicilerinin kullanımını tamamen devre dışı bırakabilirsiniz trigger: none .

# A pipeline with no CI trigger
trigger: none

Önemli

Bir dala değişiklik gönderdiğinizde, bu daldaki YAML dosyası, bir CI çalıştırmasının başlatılıp başlatılmadığını belirleyecek şekilde değerlendirilir.

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

Bireysel işlemeler için CI atlanıyor

ayrıca, bir işlemenin normalde tetikleyeceği bir işlem hattını çalıştırmayı atlayıp Azure Pipelines söyleyebilirsiniz. yalnızca işlem [skip ci] iletisi veya baş yürütmenin açıklamasına dahil edin ve Azure Pipelines cı çalıştırmayı atlar. Aşağıdaki çeşitlerden herhangi birini de kullanabilirsiniz.

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

Koşullarda Tetikleyici türünü kullanma

Bu, çalıştırmayı Başlatan tetikleyicinin türüne bağlı olarak, işlem hattınızda farklı adımlar, işler veya aşamalar çalıştırmak için yaygın bir senaryodur. Bunu sistem değişkenini kullanarak yapabilirsiniz Build.Reason . Örneğin, çekme isteği doğrulamalarından dışlamak için adım, iş veya aşamalara 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ındır. Örneğin, uygulamanızın belgelerini oluşturmak için bir işlem hattına ve kaynak kodu oluşturmak için başka bir işlem hattına sahip olabilirsiniz. Bu işlem hatlarında uygun dal filtreleri ve yol filtreleri ile CI Tetikleyicileri yapılandırabilirsiniz. Örneğin, klasöre bir güncelleştirme gönderdiğinizde bir işlem hattının tetiklenmesi docs ve uygulama kodunuza bir güncelleştirme gönderdiğinizde başka bir işlem hattının tetiklenmesi isteyebilirsiniz. Bu durumlarda, yeni bir dal oluşturulduğunda işlem hatlarının nasıl tetikleneceğini anlamanız gerekir.

Deponuzda yeni bir dalı (dal filtreleriyle eşleşen) gönderdiğinizde bu davranış aşağıda verilmiştir:

  • İşlem hattınızda yol filtreleri varsa, yalnızca yeni dal bu yol filtresiyle eşleşen dosyalarda değişiklik içeriyorsa tetiklenir.
  • İşlem hattınızda yol filtreleri yoksa, yeni dalda hiçbir değişiklik olmasa bile bu işlem tetiklenir.

Joker karakterler

Bir dal veya etiket belirtirken, tam bir ad veya joker karakter kullanabilirsiniz. Joker karakter desenleri * sıfır veya daha fazla karakterle eşleşmek ve ? tek bir karakterle eşleştirmek için izin verir.

  • Eğer modelinizi bir YAML işlem hattında başlatırsanız, * düzeni gibi tırnak içine sarmalısınız "*-releases" .
  • Dallar, Etiketler ve yollar için, bir joker karakter, düzenin herhangi bir yerinde görünebilir.
trigger:
  branches:
    include:
    - master
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR Tetikleyicileri

Çekme isteği (PR) Tetikleyicileri, bir çekme isteği belirtilen hedef dallarından biriyle açıldığında veya bu tür bir çekme isteğinde güncelleştirmeler yapıldığında bir işlem hattının çalışmasına neden olur.

Dallar

Çekme isteklerinizi doğrularken hedef dalları belirtebilirsiniz. Örneğin, ve ile hedeflenen çekme isteklerini doğrulamak için masterreleases/* aşağıdaki pr tetikleyiciyi kullanabilirsiniz.

pr:
- master
- releases/*

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

Dalın tam adını (örneğin, master ) veya bir joker karakter belirtebilirsiniz (örneğin, releases/* ).

Not

Değişkenler çalışma zamanında değerlendirildiğinden (tetikleyici tetiklendikten sonra), Tetikleyiciler içinde değişkenler kullanamazsınız.

Not

YAML dosyalarını yazmak için Şablonlar kullanıyorsanız, yalnızca işlem hattının ana YAML dosyasında Tetikleyiciler belirtebilirsiniz. Şablon dosyalarında Tetikleyiciler 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şlemesiniişaret eder. Çekme isteği doğrulama işlem hattı, bu başvurunun işaret ettiği kaydı oluşturur. Bu, işlem hattını çalıştırmak için kullanılan YAML dosyasının aynı zamanda kaynak ve hedef dal arasında bir birleştirme olduğunu gösterir. Sonuç olarak, çekme isteğinin kaynak dalında YAML dosyasında yaptığınız değişiklikler, hedef daldaki YAML dosyası tarafından tanımlanan davranışı geçersiz kılabilir.

prYAML dosyanızda hiçbir tetikleyici görünmezse, aşağıdaki tetikleyiciyi yazdıysanız, çekme isteği doğrulamaları tüm dallar için otomatik olarak etkinleştirilir pr . Bu yapılandırma herhangi bir çekme isteği oluşturulduğunda ve işlemeler herhangi bir etkin çekme isteğinin kaynak dalına geldiğinde bir derlemeyi tetikler.

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

Önemli

prDalların bir alt kümesiyle bir tetikleyici belirttiğinizde, bir işlem hattı yalnızca güncelleştirmeler söz konusu dallara itildiğinde tetiklenir.

Belirli dalları hariç tutmaları gereken daha karmaşık Tetikleyiciler için aşağıdaki örnekte gösterildiği gibi tam sözdizimini kullanmanız gerekir.

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

Yollar

Dahil etmek veya hariç tutmak için dosya yolları belirtebilirsiniz. Örnek:

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

İpuçları:

  • Joker karakterler yol filtreleriyle desteklenmez.
  • Yollar her zaman deponun köküne göre belirtilir.
  • Yol filtrelerini ayarlamazsanız, deponun kök klasörü varsayılan olarak örtülü olarak dahil edilir.
  • Bir yolu dışladığınızda, daha derin bir klasöre niteetmediğiniz müddetçe da dahil edilemez. Örneğin, /Tools dışlandıysanız, /Tools/Trigger-runs-on-bu işlemleri dahil edebilirsiniz.
  • Yol filtrelerinin sırası ne kadar önemlidir.
  • 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 (tetikleyici başlatıldıktan sonra) değerlendirildiğinden, yollarda değişkenler kullanamazsınız.

Birden çok PR Güncelleştirmesi

Bir çekme isteği için ek güncelleştirmelerin aynı çekme isteği için devam eden doğrulama çalıştırmalarını iptal edip etmeyeceğini belirtebilirsiniz. Varsayılan değer: true.

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

Taslak PR doğrulaması

Varsayılan olarak, çekme isteği taslak çekme isteklerinde ve incelenmeye hazır çekme isteklerinin tetiklenmesi tetikler. Taslak çekme istekleri için çekme isteği tetikleyicilerini devre dışı bırakmak için drafts özelliğini olarak ayarlayın false .

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

PR doğrulamasından çıkma

' İ belirterek çekme isteği doğrulamadan vazgeçebilirsiniz pr: none .

# no PR triggers
pr: none

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

Not

prTetikleyiciniz tetiklenemez, prbölümündeki sorun giderme adımlarını izleyin.

Not

Taslak çekme istekleri bir işlem hattı tetiklemez.

Korumalı dallar

Bir dalı hedefleyen her bir COMMIT veya çekme isteğiyle bir doğrulama derlemesini çalıştırabilir, hatta doğrulama oluşturma işlemi başarılı olana kadar çekme isteklerinin birleştirilmesini engelleyebilirsiniz.

bir GitHub deposu için zorunlu doğrulama yapılarını yapılandırmak için, sahibi, yönetici rolüne sahip bir ortak çalışan veya yazma rolüne sahip bir GitHub kuruluş üyesi olmanız gerekir.

  1. ilk olarak, depo için bir işlem hattı oluşturun ve en az bir kez derleyin, böylece durumunun GitHub nakledilmesini sağlar ve böylece işlem hattının adının GitHub farkında olur.

  2. sonra, deponun ayarlarındaki korunan dalları yapılandırmak için GitHub belgelerini izleyin.

    Durum denetimi için durum denetimleri listesinden işlem hattının adını seçin.

    GitHub ardışık düzen durumu denetimi

Önemli

İşlem hatlarınız bu listede görünmüyorsa, lütfen şunlardan emin olun:

Dış kaynaklardaki katkılar

GitHub deponuz açık kaynak ise, herkesin işlem hattının derleme sonuçlarını, günlüklerini ve test sonuçlarını oturum açmadan görüntülemesi için Azure DevOps projenizi genel hale getirebilirsiniz. Kuruluşunuzun dışındaki kullanıcılar deponuzu çatalla ve çekme istekleri gönderdiklerinde, bu çekme isteklerini otomatik olarak doğrulayan derlemelerin durumunu görüntüleyebilirler.

dış kaynaklardaki katkıları kabul ettiğinizde ortak bir projede Azure Pipelines kullanırken aşağıdaki noktaları göz önünde bulundurmanız gerekir.

Erişim kısıtlamaları

Genel projelerde işlem hatlarını çalıştırmaya devam ediyorken aşağıdaki erişim Azure DevOps dikkat olun:

  • Sır -larını: Varsayılan olarak, işlem hattınız ile ilişkili gizli diziler, çekme isteği onayları için kullanılamaz. Bkz. Fork'lardan gelen katkıları doğrulama.
  • Çapraz proje erişimi: Bir genel Azure DevOps tüm işlem hatları, projeyle sınırlı bir erişim belirteci ile çalıştırılmıştır. Pipelines projesinde derleme yapıtları veya test sonuçları gibi kaynaklara yalnızca proje içinde erişebilirsiniz. Bu kaynaklar, Azure DevOps projesinde yer alan projelere erişebilirsiniz.
  • Azure Artifacts paketleri: İşlem hatlarının Azure Artifacts paketlere erişmesi gerekirse, Project Derleme Hizmeti hesabına paket akışlarına erişmek için açıkça izin verebilirsiniz.

Mürekkeplerden katkılar

Önemli

Bu ayarlar işlem hattınızı güvenlikle etkiler.

İşlem hattı oluşturma, deponun mürekkeplerinden gelen çekme istekleri için otomatik olarak tetiklenir. 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 Pipelinesseç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 mürekkeplerinden çekme istekleri oluşturma onay kutusunu etkinleştirin veya devre dışı kaldırın.

Varsayılan olarak GitHub işlem hatlarıyla, derleme işlem hattınız ile ilişkili gizli diziler, çekme isteği derlemeleri için kullanılamaz. Bu gizli diziler, GitHub Enterprise Server işlem hatlarıyla varsayılan olarak etkindir. Gizli diziler şunlardır:

İşlem hatlarında bu GitHub atlamak için, Gizli dizileri, mürekkep derlemeleri için kullanılabilir yap onay kutusunu etkinleştirin. Bu ayarın güvenlik üzerindeki etkisinin farkında olmak.

Önemli güvenlik konuları

Bir GitHub kullanıcı deponun bir toksunu oluşturabilir, değiştirebilir ve depoda değişiklik öneren bir çekme isteği oluşturabilir. Bu çekme isteği, tetiklenen derlemenizin bir parçası olarak çalıştıracak kötü amaçlı kod içerebilir. Bu tür kodlar aşağıdaki yollarla zarara neden olabilir:

  • İşlem hattından gizli dizileri sızdır. Deponuzu genel veya güvenilmeyen kullanıcılar otomatik olarak derlemeleri tetikleyen çekme istekleri göndere bilirse, bu riski azaltmak için Gizli dizileri derlemeler 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 çalması için aracıyı çalıştıran makinenin güvenliğini tehlikeye at. Bunu azaltmak için:

    • Microsoft tarafından barındırılan aracı havuzunu kullanarak, mürekkeplerden çekme istekleri oluşturma. Microsoft tarafından barındırılan aracı makineleri bir derleme tamamlandıktan hemen sonra silinir, bu nedenle güvenliği tehlikeye atılmışsa kalıcı bir etki olmaz.

    • Kendi içinde barındırılanbir aracı kullanmanız gerekirse, deponuz özel değilse ve çekme isteği oluşturuculara güvenmedikçe, gizli dizileri depolamayın veya gizli dizileri kullanan başka derlemeler ve sürümler gerçekleştirmeyin.

Açıklama tetikleyicileri

Depo ortak çalışanları, bir işlem hattını el ile çalıştırmak için çekme isteğiyle ilgili yorumda olabilir. Bunu neden yapmak istemenin yaygın nedenlerinden birkaçı şu şekildedir:

  • Değişiklikleri gözden geçirilinceye kadar bilinmeyen kullanıcılardan otomatik olarak çekme istekleri oluşturmak istemeyebilirsiniz. Ekip üyelerinden birinin önce kodunu gözden geçirmesini ve ardından işlem hattını çalıştırması gerekir. Bu genellikle, forked depolardan katkıda bulunan kodlar hazırlarken güvenlik önlemi olarak kullanılır.
  • İsteğe bağlı bir test paketi veya ek doğrulama derlemesi çalıştırmak istiyor olabilir.

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ışlamamanızı sağlar.
  2. Web Azure Pipelines işlem hattınızı düzenleyin ve Diğer eylemler , Tetikleyiciler'iseçin. Ardından Çekme isteği doğrulaması'nın altındaÇekme isteği eklemeden önce takım üyesinin yorumunu gerektir'i etkinleştirin.
    • Çekme isteğinden önce bir ekip üyesinin yorumunu gerektirmek için Tüm çekme istekleri üzerinde'yi seçin. Bu iş akışıyla, ekip üyesi çekme isteğini gözden tamamlar ve çekme isteği güvenli kabul edildiktan sonra derlemeyi bir açıklamayla tetikler.
    • Yalnızca ekip üyesi olmayan üyelerin çekme istekleri için bir ekip üyesinin yorumunu gerektirmek için, yalnızca ekip üyesi olmayan bir üye tarafından çekme isteği yapılırken bunu seçin. Bu iş akışında, bir takım üyesinin derlemeyi tetiklemek için ikincil bir ekip üyesinin incelemesine ihtiyacı yok.

Bu iki değişiklikle, çekme isteği doğrulama derlemesi yalnızca ekip üyesi olmayan üyelerin çekme isteklerinde seçilmedikçe ve çekme isteği bir ekip üyesi tarafından yapılıyorsa otomatik olarak tetiklanmaz. Yalnızca 'Yazma' iznine sahip depo sahipleri ve ortak çalışanlar, veya ile çekme isteğine yorum yazarak derlemeyi /AzurePipelines run/AzurePipelines run <pipeline-name> tetikler.

Aşağıdaki komutlar, açıklamalarda Azure Pipelines için ve olabilir:

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

Not

Daha fazla açıklama için yerine kullanarak /azp açıklamaya yer ve ardından baksanıza. /AzurePipelines

Önemli

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

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

Gerekli depo izinlerine sahipsiniz ancak yorumlarınız işlem hatları tetiklenene kadar üyeliğinizin deponun kuruluşunda genel olduğundan emin olun veya kendinizi doğrudan depo ortak çalışanı olarak ekleyin. Azure Pipelines doğrudan ortak çalışanlar olmadığı veya doğrudan ortak çalışan bir takıma ait olmadığı sürece özel kuruluş üyelerini göremiyorum. Kuruluş üyeliğinizi burada GitHub genel olarak değiştirebilirsiniz (yerine Your-Organization kuruluş adınızla değiştirin): https://github.com/orgs/Your-Organization/people .

Kullanıma alma

İşlem hattı tetiklendiğinde Azure Pipelines Git deposundan Azure Repos çeker. Bunun nasıl olduğunu çeşitli yönleriyle kontrol etmek için.

Not

İşlem hattınıza bir onay adımı dahil etmek için şu komutu çalıştırıyoruz: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin . Bu, ihtiyaçlarınızı karşılayamazsa, tarafından yerleşik iadeyi dışlamayı seçebilir ve ardından kendi onay işleminizi gerçekleştirmek için bir checkout: none betik görevi kullanabilirsiniz.

Git'in tercih edilen sürümü

Windows aracı kendi Git kopyasıyla birlikte gelir. Dahil edilen kopyayı kullanmak yerine kendi Git'inizi sağlamak isterseniz olarak System.PreferGitFromPathtrue ayarlayın. Bu ayar, varsayılan olmayan aracılarda Windows olur.

Çıkış yolu

Tek bir depoyu kullanıma alırsanız, kaynak kodunuz varsayılan olarak adlı bir dizine iade s edilir. YAML işlem hatları için, ile belirterek bunu checkoutpath değiştirebilirsiniz. Belirtilen yol ile $(Agent.BuildDirectory) görelidir. Örneğin, kullanıma alma yolu değeri ve ise mycustompath$(Agent.BuildDirectory) kaynak kodu içine C:\agent\_work\1C:\agent\_work\1\mycustompath denetlenir.

Birden çok adım kullanıyorsanız ve birden çok depoyu kontrol ediyorsanız ve kullanarak klasörü açıkça belirtmezseniz, her depo, depodan sonra adlı bir alt checkoutpaths klasöre yerleştirilir. Örneğin, ve adlı iki depoyu kullanıma toolscode aldıysanız, kaynak kodu ve içine C:\agent\_work\1\s\toolsC:\agent\_work\1\s\code denetlenir.

Lütfen ödeme yolu değerinin üzerinde herhangi bir dizin düzeyine gitmek için ayarlanamaysa da geçerli bir ödeme yolu (örneğin) ile sonuçlansa da gibi bir değer (örneğin , ) $(Agent.BuildDirectory)path\..\anotherpathC:\agent\_work\1\anotherpath..\invalidpathC:\agent\_work\invalidpath olmayacaktır.

Bu ayarı işlem path hattınızı path 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

Altmodüller

Altmodüllerden submodules dosya submodules işlem hattınızı iade et adımı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

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

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

  • Denetiminden

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

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

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

        bu örnekte, alt modül aynı Azure DevOps kuruluştaki bir depoya (FabrikamFiber), ancak farklı bir projede (FabrikamFiberProject) başvurur. Ana depodan kaynakları almak için aracı tarafından kullanılan kimlik bilgileri, alt modüller için kaynakları almak için de kullanılır. Bu, iş erişim belirtecinin ikinci projedeki depoya erişimine sahip olmasını gerektirir. Yukarıdaki bölümde açıklandığı gibi iş erişim belirtecini kısıtladıysanız bunu yapamazsınız. İş erişim belirtecinin ikinci projedeki depoya, (a) ikinci projedeki proje yapı hizmeti hesabına açıkça erişim vererek veya (b) tüm kuruluşun proje kapsamlı belirteçleri yerine koleksiyon kapsamlı erişim belirteçleri kullanarak erişmesine izin verebilirsiniz. Bu seçenekler ve bunların güvenlik etkileri hakkında daha fazla bilgi için bkz. erişim depoları, yapıtlar ve diğer kaynaklar.

      • Bu bir tanesi kullanıma alınmamış: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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

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

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

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

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

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

Not

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

Yüzeysel getirme

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

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

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

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

Not

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

Kaynakları eşitleme

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

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

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

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

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

Not

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

Derlemeyi temizle

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

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

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

Not

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

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

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

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

git clean -ffdx
git reset --hard HEAD

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

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

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

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

  • kaynaklar: siler ve yeniden oluşturur . 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.

Kaynakları etiketle

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

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

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

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

Klasik düzenleyiciden YAML kaynakları Al ' ı seçin  .

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

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

İlk dört değişken önceden tanımlanmıştır. My.Variable , My.Variablesizin tarafınızdan tanımlanabilir.

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

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

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

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

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

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

Durum güncelleştirmeleri

Azure Pipelines GitHub temel durumlara ve GitHub denetim çalışmasına geri gönderen iki tür durum vardır. GitHub denetimleri işlevselliği yalnızca GitHub uygulamalarla kullanılabilir.

İşlem hattı durumları GitHub Kullanıcı arabirimindeki çeşitli yerlerde görünür.

  • PR 'ler için, çekme isteği konuşmaları sekmesinde görüntülenir.
  • Bireysel yürütmeler için, depo, kayıt zamanından sonra depoların işlemeler sekmesinden sonra durum işaretinin üzerine getirildiğinde görüntülenir.

PAT veya OAuth GitHub bağlantıları

PAT veya OAuth GitHub bağlantıları kullanan işlem hatları için, durumlar çalıştırmayı tetikleyen işlemeye/PR 'ye geri gönderilir. bu tür güncelleştirmeleri postalamak için GitHub durum apı 'si kullanılır. Bu durumlar, sınırlı bilgiler içerir: ardışık düzen durumu (başarısız, başarı), derleme işlem hattına geri bağlanacak URL ve durumun kısa bir açıklaması.

PAT veya OAuth GitHub bağlantıları için durumlar yalnızca çalıştırma düzeyinde gönderilir. Diğer bir deyişle, bir çalıştırmanın tamamı için tek bir durumun güncelleştirilmesini sağlayabilirsiniz. Bir çalıştırmada birden çok iş varsa, her iş için ayrı bir durum postalayabilirsiniz. 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önderilir. GitHub denetimleri, ardışık düzen durumu ve test, kod kapsamı ve hata hakkında ayrıntılı bilgi gönderilmesine izin verir. GitHub denetimleri apı 'si buradabulunabilir.

GitHub uygulamasını kullanan her işlem hattı için, her bir işin çalıştığı her iş için denetim, genel çalışma için geri gönderilir.

bir PR/commıt için bir veya daha fazla denetim çalıştırıldığında GitHub üç seçeneğe izin verir. Tek tek denetimi "yeniden çalıştırmayı" seçebilirsiniz, bu PR/COMMIT üzerinde başarısız olan tüm denetimleri yeniden çalıştırın ya da başlangıçta başarılı olup olmadıklarında tüm denetimleri yeniden çalıştırın.

GitHub denetimleri yeniden çalıştır

denetim çalıştırması adının yanındaki "yeniden çalıştır" bağlantısına tıkladığınızda, denetim çalıştırmasının çalıştırıldığı çalıştırmaya yeniden denenerek Azure Pipelines. Sonuç çalıştırması aynı çalışma numarasına sahip olur ve ilk derleme olarak kaynak kodu, yapılandırma ve YAML dosyasının aynı sürümünü kullanacaktı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ıkladığınızda aynı etkiye sahip olur. Bu davranış, Azure Pipelines Kullanıcı arabirimindeki "çalıştırmayı yeniden dene" seçeneğine tıklanmakla aynıdır. "Tüm denetimleri yeniden çalıştır" seçeneğine tıklamak, yeni bir çalıştırma numarası ile yeni bir çalıştırmaya neden olur ve yapılandırma veya YAML dosyasındaki değişiklikleri seçer.

SSS

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

Bağlantı türleri

tetikleyicilerle ilgili sorunları gidermek için, ardışık düzen için kullandığım GitHub bağlantısının türünü nasıl anlayabilirim?

tetikleyicilerle ilgili sorunları giderme, işlem hatınızda kullandığınız GitHub bağlantısının türüne bağlıdır. GitHub ve Azure Pipelines arasında bağlantı türünü belirlemenin iki yolu vardır.

  • GitHub: bir depo, GitHub uygulamasını kullanacak şekilde ayarlandıysa, pr 'ler ve yürütmelerde durumlar denetim çalıştırmaları olur. deponun OAuth veya PAT bağlantılarıyla Azure Pipelines ayarlandıysa, durumlar "eski" durum tarzına sahip olur. durumların denetim çalıştırmaları veya basit durumların GitHub bir PR 'de "konuşma" sekmesine baktığın belirlenmesi için hızlı bir yol.

    • "Ayrıntılar" bağlantısı denetimler sekmesine yeniden yönlendirirse, bir denetim çalıştıralım ve depo uygulamayı kullanıyor.
    • "ayrıntılar" bağlantısı Azure DevOps işlem hattına yeniden yönlendirirse, durum "eski stil" durumudur ve depo uygulamayı kullanmıyor demektir.
  • Azure Pipelines: 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ı için klasik düzenleyiciyi açmak üzere Tetikleyiciler ' i seçin. Ardından, YAML sekmesini ve ardından kaynakları al adımını seçin. Bağlantı kullanılarak yetkilendirilmiş bir başlık görürsünüz: işlem hattını GitHub ile tümleştirmede kullanılan hizmet bağlantısını gösterir. Hizmet bağlantısının adı bir köprüdür. Hizmet bağlantısı özelliklerine gitmek için bunu seçin. Hizmet bağlantısının Özellikleri, kullanılmakta olan bağlantı türünü gösterecektir:

    • Azure Pipelines uygulama GitHub uygulama bağlantısını gösterir
    • OAuth OAuth bağlantısını gösterir
    • personalaccesstoken , Pat kimlik doğrulamasını gösteriyor

Nasıl yaparım?, işlem hatımı OAuth yerine GitHub uygulamayı kullanacak şekilde değiştirin mi?

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

  1. buraya gidin ve deponuzun GitHub kuruluşa uygulamayı yüklersiniz.
  2. yükleme sırasında, bir Azure DevOps organizasyonu ve proje seçmek için Azure DevOps yönlendirilirsiniz. Uygulamasını kullanmak istediğiniz klasik derleme işlem hattını içeren organizasyonu ve projeyi seçin. bu seçenek GitHub uygulama yüklemesini Azure DevOps kuruluşunuzla ilişkilendirir. yanlış seçeneğini belirlerseniz, GitHub org GitHub uygulamayı kaldırmak ve baştan başlamak için bu sayfayı ziyaret edebilirsiniz.
  3. Görüntülenen sonraki sayfada yeni işlem hattı oluşturmaya devam etmeniz gerekmez.
  4. Pipelines sayfasını ziyaret ederek işlem hattınızı düzenleyin (örn., işlem https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build) hattınızı seçerek ve düzenle ' ye tıklayın.
  5. Bu bir YAML işlem hattı ise, klasik düzenleyiciyi açmak için Tetikleyiciler menüsünü seçin.
  6. İşlem hattının "kaynakları al" adımını seçin.
  7. "bağlantı kullanılarak yetkilendirilmiş" metninin bulunduğu yeşil çubukta "değiştir" e tıklayın ve uygulamayı yüklediğiniz GitHub kuruluşla aynı ada sahip GitHub uygulama bağlantısını seçin.
  8. Araç çubuğunda "Kaydet ve kuyruğa al" öğesini ve ardından "Kaydet ve kuyruğa al" seçeneğini belirleyin. Başarılı olduğundan emin olmak için kuyruğa alınan işlem hattı çalıştırmasının bağlantısına tıklayın.
  9. bir yapılandırmanın "denetimler" bölümünde başarıyla kuyruğa alındığından emin olmak için GitHub deponuzda bir çekme isteği oluşturun (veya kapatın ve yeniden açın).

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

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

işlem hattı oluşturma sırasında bir depoyu seçdiğimde, "{repo-name} deposu başka bir Azure DevOps kuruluşunda Azure Pipelines GitHub uygulamayla kullanımda."

Bu, deponuzın farklı bir kuruluştaki bir işlem hattı ile zaten ilişkilendirildiği anlamına gelir. Bu depodan alınan CI ve PR olayları, diğer kuruluşa teslim edileceği için çalışmaz. İşlem hattı oluşturmaya devam etmeden önce diğer kuruluşa eşlemeyi kaldırmak için gerçekleştirmeniz gereken adımlar aşağıda verilmiştir.

  1. GitHub deponuzda bir çekme isteği açın ve yorumu yapın /azp where . bu, deponun eşlendiği Azure DevOps organizasyonunu geri bildirir.

  2. eşlemeyi değiştirmek için GitHub kuruluştan uygulamayı kaldırın ve yeniden yükleme. Yeniden yüklediğinizde, Azure DevOps tekrar 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 ama işlem hattı tetiklenm yok.

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

  • İşlem hattını GitHub için uygulama bağlantısını mı GitHub? Sahip olduğunu bağlantı türünü belirlemek için bkz. Bağlantı türleri. Bir uygulama bağlantısı GitHub aşağıdaki adımları izleyin:

    • Eşleme, GitHub ve Azure DevOps? GitHub depoda bir çekme isteği açın ve yorumunu /azp where yapma. Bu, Azure DevOps eşlenen kuruluşa geri rapor sağlar.

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

      • Farklı bir Azure DevOps kuruluş bildiriliyorsa, birisi farklı bir kuruluşta bu depo için zaten bir işlem hattı hazırlar. Şu anda yalnızca bir GitHub kuruluşa eşleyebilecek sınırlamaya DevOps vardır. Otomatik olarak yalnızca ilk kuruluş Azure DevOps işlem hatları tetiklenir. Eşlemeyi değiştirmek için uygulamayı GitHub kaldırın ve yeniden yükleyin. Yeniden yükleyiciyi yeniden yükleyiciye yeniden yönlendirilmişken doğru kuruluşu Azure DevOps.

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

    1. OAuth ve PAT bağlantıları, güncelleştirmeleri web kancalarına ileterek Azure Pipelines. Bu GitHub, deponun ayarlarına ve ardından Web Kancaları'ne gidin. Web kancaları olduğunu doğrulayın. Genellikle üç web kancası (push, pull_request ve issue_comment. Yoksa, hizmet bağlantısını yeniden oluşturmanız ve işlem hattını yeni hizmet bağlantısını kullanmak üzere güncelleştirmeniz gerekir.

    2. GitHub web kancalarının her bir öğesini seçin ve kullanıcının işlemeye karşılık gelen yükün mevcut olduğunu ve Azure DevOps. Olay, Azure DevOps'a iletilene kadar burada bir hata Azure DevOps.

  • Bu Azure DevOps trafiği, GitHub. Bu Azure Pipelines bir bildirim aldığında, GitHub ile iletişim GitHub ve YAML dosyası hakkında daha fazla bilgi getirmeye çalışır. Çok sayıda güncelleştirme ve çekme isteği olan bir repo varsa, bu çağrı bu tür azaltma nedeniyle başarısız olabilir. Bu durumda, toplu işlem veya daha katı yol/dal filtreleri kullanarak derlemelerin sıklığını azaltabilirsiniz.

  • İşlem hattınız duraklatıldı mı yoksa devre dışı mı bırakıldı? İşlem hattının düzenleyicisini açın ve kontrol etmek Ayarlar seçin. İşlem hattınız duraklatıldı veya devre dışı bırakıldı, tetikleyiciler çalışmıyor.

  • YAML dosyasını doğru dalda mı güncelleştirildi? Bir dala güncelleştirme iletirsiniz, ci davranışını aynı dalda YAML dosyası yönetir. Bir kaynak dala bir güncelleştirme iletirsanız, kaynak dalı hedef dalla birleştirme sonucunda ortaya çıkan YAML dosyası, PR davranışını yönetir. Doğru dalda 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ımladığınız zaman dallar, etiketler ve yollar için hem dahil et hem de hariç tut yan tümceleri belirtebilirsiniz. include yan tümcesi işlemenizin ayrıntılarıyla eş olduğundan ve exclude yan tümcesi tarafından dışlanmaz. Tetikleyicilerin söz dizimlerini denetleyin ve doğru olduğundan emin olun.

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

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

  • Değişikliklerinizi yaptığınız dalları veya yolları dışladınız mı? Bir değişikliği dahil edilen dalda yer alan bir yola iterek test. Tetikleyicilerde yolların büyük/büyük/büyük harfe duyarlı olduğunu unutmayın. Tetikleyicilerde yolları belirtirken gerçek klasörlerle aynı durumu kullanmaya emin olun.

  • Yeni bir dal mı itişledin? Öyleyse, yeni dal yeni bir çalıştırma başlatamayyr. "Yeni dallar oluşturulduğunda tetikleyicilerin davranışı" bölümüne bakın.

CI veya PR tetikleyicilerim iyi çalışıyor. Ancak artık çalışmayı durdurdular.

İlk olarak önceki soruda yer alan sorun giderme adımlarını izleyin. Ardından aşağıdaki ek adımları izleyin:

  • PR'niz birleştirme çakışmaları mı var? İşlem hattını tetiklemeden çekme işlemi için açın ve birleştirme çakışması olup olmadığını kontrol edin. Birleştirme çakışmalarını çözümle.

  • Anında İlerlerken veya PR olaylarını işlemede gecikme mi yaşıyorsunuz? Genellikle sorunun tek bir işlem hattına özgü olduğunu veya projenizin tüm işlem hatları ya da depolar için ortak olduğunu görerek bunu doğrularsiniz. Repos'lardan herhangi biri için yapılan bir itme veya PR güncelleştirmesi bu belirtileri sergilese, güncelleştirme olaylarını işlemede gecikmeler yaşanıyor olabilir. Durum sayfamızda hizmet kesintisi yaşanıyor mu? Durum sayfasında bir sorun varsa ekibimizin bu sorun üzerinde çalışmaya başlamış olması gerekir. Sorunla ilgili güncelleştirmeler için sayfayı sık sık kontrol edin.

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

Koda katkıda bulunmak için gerekli izinlere sahip kullanıcılar YAML dosyasını güncelleştirin ve ek dalları dahil edin/hariç tutabilirsiniz. Sonuç olarak, kullanıcılar YAML dosyalarına kendi özellik veya kullanıcı dallarını dahil etmek ve bu güncelleştirmeyi bir özellik veya kullanıcı dalına itmek için kullanılabilir. Bu, işlem hattının bu dalda yapılan tüm güncelleştirmeler için tetiklenene neden olabilir. Bu davranışı önlemek için şunları yapmak gerekir:

  1. İşlem hattını kullanıcı arabiriminde Azure Pipelines düzenleyin.
  2. Tetikleyiciler menüsüne gidin.
  3. Buradan YAML sürekli Tümleştirme tetikleyicilerini geçersiz kıl'ı seçin.
  4. Tetikleyici için dahil etmek veya dışlamak istediğiniz dalları belirtin.

Bu adımları izleyebilirsiniz. YAML dosyasında belirtilen CI tetikleyicileri yoksayılır.

Başarısız olan iade

Geri 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, bir kaynak kesintisi GitHub. Veri deposundaki depoya GitHub ve mümkün olduğundan 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, ittirmekte olduğunu dalda yaml dosyası bir CI derlemesi çalıştıracak olup görmek için değerlendirilir.
  • Çekme çekme işlemi tetikleyicileri için, pr'nin kaynak ve hedef dallarının birleştirilmesinden elde edilen YAML dosyası, çekme işlemi derlemenin çalıştırılamayacak şekilde değerlendirilir.

Eksik durum güncelleştirmeleri

GitHub'daki PR'Azure Pipelines durumu güncelleştirmeme nedeniyle engellenmiş.

Bu, verilerle iletişim kuramama Azure DevOps geçici bir hata GitHub. GitHub uygulamasını GitHub iade GitHub deneyin. Veya sorunun çözülebilir olup olabıı görmek için PR'ye önemsiz bir güncelleştirme de güncelleştirmeyi de güncelleştirmeyi de s gerektir.