İşlem hattınızda işleri belirtme

Makale
04/04/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

İşlem hattınızı işler halinde düzenleyebilirsiniz. Her işlem hattının en az bir işi vardır. İş, birim olarak sıralı olarak çalışan bir dizi adımdır. Başka bir deyişle iş, çalıştırılacak zamanlanabilir en küçük çalışma birimidir.

İşlem hattını oluşturan temel kavramlar ve bileşenler hakkında bilgi edinmek için bkz . Yeni Azure Pipelines kullanıcıları için temel kavramlar.

Azure Pipelines, YAML işlem hatları için iş önceliğini desteklemez. İşlerin ne zaman çalıştırılacağını denetlemek için koşulları ve bağımlılıkları belirtebilirsiniz.

En basit durumda işlem hattının tek bir işi vardır. Bu durumda, şablon kullanmadığınız sürece anahtar sözcüğünü job açıkça kullanmanız gerekmez. YAML dosyanızdaki adımları doğrudan belirtebilirsiniz.

Bu YAML dosyası, Microsoft tarafından barındırılan bir aracıda çalışan ve çıkışını veren Hello worldbir işe sahiptir.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Bu işte daha fazla özellik belirtmek isteyebilirsiniz. Bu durumda anahtar sözcüğünü job kullanabilirsiniz.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

İşlem hattınızın birden çok işi olabilir. Bu durumda anahtar sözcüğünü jobs kullanın.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

İşlem hattınızın her birinin birden çok işi olan birden çok aşaması olabilir. Bu durumda anahtar sözcüğünü stages kullanın.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

İş belirtmek için tam söz dizimi şöyledir:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

İş belirtmek için tam söz dizimi şöyledir:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

İşinizin birincil amacı uygulamanızı dağıtmaksa (uygulamanızı derlemek veya test etmek değil), dağıtım işi adlı özel bir iş türü kullanabilirsiniz.

Dağıtım işinin söz dizimi şöyledir:

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

içinde dağıtım görevleri jobiçin adımlar ekleyebilirsiniz, ancak bunun yerine bir dağıtım işi kullanmanızı öneririz. Dağıtım işinin birkaç avantajı vardır. Örneğin, dağıttığınız şeyin geçmişini görebilme gibi avantajları içeren bir ortama dağıtabilirsiniz.

İş türleri

İşler, çalıştıkları yere bağlı olarak farklı türlerde olabilir.

YAML
Klasik

Aracı havuzu işleri, aracı havuzundaki bir aracıda çalışır.
Sunucu işleri, Azure DevOps Server üzerinde çalışır.
Kapsayıcı işleri , aracı havuzundaki bir aracının üzerindeki kapsayıcıda çalışır. Kapsayıcı seçme hakkında daha fazla bilgi için bkz . Kapsayıcı işlerini tanımlama.

YAML
Klasik

Aracı havuzu işleri, aracı havuzundaki bir aracıda çalışır.
Sunucu işleri, Azure DevOps Server üzerinde çalışır.

Aracı havuzu işleri

Bunlar en yaygın iş türleridir ve aracı havuzundaki bir aracıda çalışır.

Microsoft tarafından barındırılan aracıları kullanırken, işlem hattındaki her iş yeni bir aracı alır.
Bir aracının işinizi çalıştırmak için sahip olması gereken özellikleri belirtmek için şirket içinde barındırılan aracılarla ilgili talepleri kullanın. Ardışık işler için aynı aracıyı, aracı havuzunuzda işlem hattınızın taleplerine uyan birden fazla aracı olup olmadığına bağlı olarak alabilirsiniz. Havuzunuzda işlem hattının talepleriyle eşleşen tek bir aracı varsa, işlem hattı bu aracı kullanılabilir olana kadar bekler.

Not

talepler ve özellikler, işlerin işin gereksinimlerini karşılayan bir aracıyla eşleştirilmesi için şirket içinde barındırılan aracılarla kullanılmak üzere tasarlanmıştır. Microsoft tarafından barındırılan aracıları kullanırken, aracı için işin gereksinimleriyle eşleşen bir görüntü seçersiniz, bu nedenle Microsoft tarafından barındırılan bir aracıya özellik eklemek mümkün olsa da, Microsoft tarafından barındırılan aracılarla özellikleri kullanmanız gerekmez.

YAML
Klasik

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Veya birden çok talep:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Aracı özellikleri hakkında daha fazla bilgi edinin.

Sunucu işleri

Bir sunucu işindeki görevler tarafından düzenlenir ve sunucuda yürütülür (Azure Pipelines veya TFS). Sunucu işi için bir aracı veya herhangi bir hedef bilgisayar gerekmez. Bir sunucu işinde şu anda yalnızca birkaç görev destekleniyor. Sunucu işi için en uzun süre 30 gündür.

Aracısız işler tarafından desteklenen görevler

Şu anda aracısız işler için yalnızca aşağıdaki görevler kullanıma hazır olarak desteklenmektedir:

Görevler genişletilebilir olduğundan, uzantıları kullanarak daha fazla aracısız görev ekleyebilirsiniz. Aracısız işler için varsayılan zaman aşımı 60 dakikadır.

YAML
Klasik

Sunucu işini belirtmek için tam söz dizimi şöyledir:

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Basitleştirilmiş söz dizimini de kullanabilirsiniz:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Bağımlılıklar

Tek bir aşamada birden çok iş tanımladığınızda, aralarındaki bağımlılıkları belirtebilirsiniz. İşlem hatları, bağımlılıkları olmayan en az bir iş içermelidir. Varsayılan olarak, değer ayarlanmadığı sürece dependsOn Azure DevOps YAML işlem hattı işleri paralel olarak çalıştırılır.

Not

Her aracı aynı anda yalnızca bir iş çalıştırabilir. Birden çok işi paralel çalıştırmak için birden çok aracı yapılandırmanız gerekir. Ayrıca yeterli paralel iş gerekir.

YAML
Klasik

Birden çok iş ve bağımlılıklarını tanımlamak için söz dizimi şöyledir:

jobs:
- job: string
  dependsOn: string
  condition: string

Sıralı olarak oluşturulan örnek işler:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Paralel olarak (bağımlılık olmadan) derleyen örnek işler:

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Fan çıkışı örneği:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Fan-in örneği:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

Koşullar

Her işin hangi koşullar altında çalıştırılacağını belirtebilirsiniz. Varsayılan olarak, bir iş başka bir işe bağımlı değilse veya bağlı olduğu tüm işler tamamlanmış ve başarılıysa çalışır. Önceki bir iş başarısız olsa bile bir işi çalıştırmaya zorlayarak veya özel bir koşul belirterek bu davranışı özelleştirebilirsiniz.

YAML
Klasik

Önceki bir işi çalıştırma durumuna göre bir işi çalıştırma örneği:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Özel koşul kullanma örneği:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

Bir işin, önceki bir işte ayarlanan bir çıkış değişkeninin değerine göre çalıştırılmasını belirtebilirsiniz. Bu durumda, yalnızca doğrudan bağımlı işlerde ayarlanan değişkenleri kullanabilirsiniz:

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

Zaman aşımları

İşiniz yanıt vermediğinde veya çok uzun süre beklediğinizde kaynakları kullanmaktan kaçınmak için işinizin ne kadar süreyle çalışmasına izin verileceği konusunda bir sınır belirlemek iyi bir fikirdir. İşi çalıştırma sınırını dakika cinsinden belirtmek için iş zaman aşımı ayarını kullanın. Değeri sıfır olarak ayarlamak, işin çalıştırabileceği anlamına gelir:

Şirket içinde barındırılan aracılarda sonsuza kadar
Microsoft tarafından barındırılan aracılarda ortak proje ve genel depo ile 360 dakika (6 saat) boyunca
Özel bir proje veya özel depoya sahip Microsoft tarafından barındırılan aracılarda 60 dakika boyunca (ek kapasite ödenmediği sürece)

Zaman aşımı süresi, iş çalışmaya başladığında başlar. İşin kuyruğa alındığı veya bir aracı beklediği süreyi içermez.

YAML
Klasik

, timeoutInMinutes iş yürütme süresi için bir sınır ayarlanmasına izin verir. Belirtilmediğinde varsayılan değer 60 dakikadır. Belirtildiğinde 0 , üst sınır kullanılır (yukarıda açıklanmıştır).

, cancelTimeoutInMinutes önceki bir görev başarısız olursa dağıtım görevi çalışmaya devam etmek üzere ayarlandığında iş iptal süresi için bir sınır ayarlanmasına izin verir. Belirtilmediğinde varsayılan değer 5 dakikadır. Değer 1 ile 35790 dakika arasında olmalıdır.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

Zaman aşımları aşağıdaki öncelik düzeyine sahiptir.

Microsoft tarafından barındırılan aracılarda işler , proje türüne göre ne kadar süreyle çalışabilecekleri ve ücretli paralel iş kullanılarak çalıştırılıp çalıştırılmadıklarıyla sınırlıdır. Microsoft tarafından barındırılan iş zaman aşımı aralığı sona erdiğinde iş sonlandırılır. Microsoft tarafından barındırılan aracılarda, işlerde belirtilen iş düzeyi zaman aşımlarından bağımsız olarak işler bu aralıktan daha uzun süre çalışamaz.
İş düzeyinde yapılandırılan zaman aşımı, işin çalışması için en uzun süreyi belirtir. İş düzeyi zaman aşımı aralığı geçtiğinde iş sonlandırılır. İş Microsoft tarafından barındırılan bir aracıda çalıştırılıyorsa, iş düzeyi zaman aşımının Microsoft tarafından barındırılan yerleşik iş düzeyi zaman aşımından büyük bir zaman aralığına ayarlanmasının hiçbir etkisi olmaz ve Microsoft tarafından barındırılan iş zaman aşımı kullanılır.
Ayrıca her görev için zaman aşımını ayrı ayrı ayarlayabilirsiniz. Bkz . görev denetimi seçenekleri. görev tamamlanmadan önce iş düzeyi zaman aşımı aralığı ularsa, görev daha uzun bir zaman aşımı aralığıyla yapılandırılmış olsa bile çalışan iş sonlandırılır.

Çok işli yapılandırma

Tek bir işten, birden çok aracı üzerinde paralel olarak birden çok iş çalıştırabilirsiniz. Bazı Örnekler:

Çoklu yapılandırma derlemeleri: Birden çok yapılandırmayı paralel olarak oluşturabilirsiniz. Örneğin, hem hem de platformlarda x86 x64 hem de debug release yapılandırmalar için bir Visual C++ uygulaması oluşturabilirsiniz. Daha fazla bilgi için bkz . Visual Studio Derlemesi - birden çok platform için birden çok yapılandırma.
Çoklu yapılandırma dağıtımları: Birden çok dağıtımı, örneğin farklı coğrafi bölgelere paralel olarak çalıştırabilirsiniz.
Çoklu yapılandırma testi: Birden çok yapılandırmayı paralel olarak test edebilirsiniz.
Çoklu yapılandırma değişkeni boş olsa bile çoklu yapılandırma her zaman en az bir iş oluşturur.

YAML
Klasik

Strateji, matrix bir işin farklı değişken kümeleriyle birden çok kez gönderilmesini sağlar. etiketi paralellik maxParallel miktarını kısıtlar. Aşağıdaki iş, Konum ve Tarayıcı değerleri belirtilen şekilde ayarlanmış şekilde üç kez gönderilir. Ancak, aynı anda yalnızca iki iş çalışır.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Not

Matris yapılandırma adları (yukarıdaki gibi US_IE ) yalnızca temel Latin alfabesi harfleri (A-Z, a-z), sayılar ve alt çizgi (_) içermelidir. Bunlar bir harf ile başlamalıdır. Ayrıca, 100 karakter veya daha kısa olmalıdır.

Matris oluşturmak için çıkış değişkenlerini kullanmak da mümkündür. Matrisi bir betik kullanarak oluşturmanız gerekiyorsa bu kullanışlı olabilir.

matrix dizeli bir JSON nesnesi içeren bir çalışma zamanı ifadesi kabul eder. Bu JSON nesnesi genişletildiğinde matris söz diziminin eşleşmesi gerekir. Aşağıdaki örnekte JSON dizesini sabit kodladık, ancak bir betik dili veya komut satırı programı tarafından oluşturulabilir.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

Çoklu yapılandırma seçeneğini kullanarak birden çok iş çalıştırmak için çarpan adlı bir değişken tanımlar ve bu çarpan için bir değer listesi belirtirsiniz. Listedeki her değer için ayrı bir iş çalıştırılır. Derleme veya dağıtım için çarpanları kullanmak için şunları yapmalısınız:

İşlem hattının Değişkenler sekmesinde veya bir değişken grubunda bir veya daha fazla değişken tanımlayın. Bu bağlamda çarpan değişkeni olarak bilinen her değişken, aracılara tek tek geçirmek istediğiniz değerlerin virgülle ayrılmış listesi olarak tanımlanmalıdır.
Çarpanlar parametresinin değeri olarak ve parantezleri olmadan $ çarpan değişkeninin adını girin. Gizli dizi değişkeninin çarpan değişkeni olarak kullanılması desteklenmez.
İşi birden fazla çarpan değişkeni için yürütmek istiyorsanız, değişken adlarını virgülle ayrılmış liste olarak girin; her biri için ve parantezlerini atlayarak $ .
Dağıtım sırasında kullanılan aracı sayısını aboneliğiniz için yapılandırdığınızdan daha az bir sayıyla sınırlamak istiyorsanız, bu değeri En fazla aracı sayısı parametresi olarak girin.

Örneğin, Konum ve Tarayıcı adlı iki değişkeni aşağıdaki gibi tanımlayabilirsiniz:

Konum = US,Europe
Tarayıcı = IE,Chrome,Edge,Firefox

Aşağıdaki yapılandırma, herhangi bir anda en fazla dört aracı kullanarak dağıtımı sekiz kez yürütür:

Artırıcılar = Location,Browser
En fazla aracı sayısı = 4

Çoklu yapılandırma ile, her biri bir veya daha fazla değişken (çarpan) için farklı bir değere sahip birden çok iş çalıştırabilirsiniz. Aynı işi birden çok aracıda çalıştırmak istiyorsanız çok aracılı paralellik seçeneğini kullanabilirsiniz. Yukarıdaki test dilimleme örneği çok aracılı seçenek aracılığıyla gerçekleştirilebilir.

Dilimleme

Aracı işi, bir test paketini paralel olarak çalıştırmak için kullanılabilir. Örneğin, tek bir aracıda büyük bir 1000 test paketi çalıştırabilirsiniz. Alternatif olarak, iki aracı kullanabilir ve her birinde paralel olarak 500 test çalıştırabilirsiniz.

Dilimleme uygulamak için, işteki görevler ait oldukları dilimi anlayacak kadar akıllı olmalıdır.

Visual Studio Test görevi, test dilimlemesi destekleyen bu tür görevlerden biridir. Birden çok aracı yüklediyseniz, Visual Studio Test görevinin bu aracılarda paralel olarak nasıl çalıştırılacağını belirtebilirsiniz.

YAML
Klasik

Strateji, parallel bir işin birçok kez çoğaltılabilmesini sağlar. değişkenler System.JobPositionInPhase ve System.TotalJobsInPhase her işe eklenir. Değişkenler daha sonra betiklerinizin içinde işlerinizi işler arasında bölmek için kullanılabilir. Bkz. Aracı işlerini kullanarak paralel ve birden çok yürütme.

Aşağıdaki iş değerleriyle System.JobPositionInPhase beş kez gönderilir ve System.TotalJobsInPhase uygun şekilde ayarlanır.

jobs:
- job: Test
  strategy:
    parallel: 5

İş değişkenleri

YAML kullanıyorsanız, iş üzerinde değişkenler belirtilebilir. Değişkenler, $(variableName) makro söz dizimi kullanılarak görev girişlerine geçirilebilir veya aşama değişkeni kullanılarak bir betik içinde erişilebilir.

YAML
Klasik

Burada, bir işte değişkenleri tanımlama ve bunları görevler içinde kullanma örneği verilmiştir.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

Koşul kullanma hakkında bilgi için bkz. Koşulları belirtme.

Çalışma alanı

Aracı havuzu işini çalıştırdığınızda, aracıda bir çalışma alanı oluşturur. Çalışma alanı, kaynağı indirdiği, adımları çalıştırdığı ve çıkışlar ürettiği bir dizindir. Çalışma alanı dizinine, değişkeni kullanılarak Pipeline.Workspace işinizde başvurulabilir. Bunun altında çeşitli alt dizinler oluşturulur:

Build.SourcesDirectory , görevlerin uygulamanın kaynak kodunu indirdiği yerdir.
Build.ArtifactStagingDirectory görevlerin işlem hattı için gereken yapıtları indirdiği veya yapıtları yayımlanmadan önce karşıya yüklediği yerdir.
Build.BinariesDirectory , görevlerin çıkışlarını yazdığı yerdir.
Common.TestResultsDirectory görevlerin test sonuçlarını karşıya yüklediği yerdir.

YAML
Klasik

$(Build.ArtifactStagingDirectory) ve $(Common.TestResultsDirectory) her derlemeden önce her zaman silinir ve yeniden oluşturulur.

Şirket içinde barındırılan bir aracıda işlem hattı çalıştırdığınızda, varsayılan olarak ve dışındaki $(Build.ArtifactStagingDirectory) $(Common.TestResultsDirectory) alt dizinlerin hiçbiri ardışık iki çalıştırma arasında temizlenmez. Sonuç olarak, görevlerin bunu kullanmak için uygulanması koşuluyla artımlı derlemeler ve dağıtımlar yapabilirsiniz. İş üzerindeki ayarı kullanarak workspace bu davranışı geçersiz kılabilirsiniz.

Önemli

Çalışma alanı temizleme seçenekleri yalnızca şirket içinde barındırılan aracılar için geçerlidir. İşler her zaman Microsoft tarafından barındırılan aracılarla yeni bir aracıda çalıştırılır.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Seçeneklerden birini belirttiğinizde clean , bunlar aşağıdaki gibi yorumlanır:

outputs: Yeni bir iş çalıştırmadan önce silin Build.BinariesDirectory .
resources: Yeni bir iş çalıştırmadan önce silin Build.SourcesDirectory .
all: Yeni bir iş çalıştırmadan önce dizinin tamamını Pipeline.Workspace silin.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Not

Aracınızın özelliklerine ve işlem hattı taleplerine bağlı olarak, her iş şirket içinde barındırılan havuzunuzda farklı bir aracıya yönlendirilebilir. Sonuç olarak, sonraki işlem hattı çalıştırmaları (veya aynı işlem hattındaki aşamalar veya işler) için yeni bir aracı alabilirsiniz, bu nedenle temizleme işlemi yapılmaması , sonraki çalıştırmaların, işlerin veya aşamaların önceki çalıştırmalardan, işlerden veya aşamalardan gelen çıkışlara erişebileceğinin garantisi değildir. Bir işlem hattı işini çalıştırmak için hangi aracıların kullanılacağını belirtmek için aracı özelliklerini ve işlem hattı taleplerini yapılandırabilirsiniz, ancak havuzda talepleri karşılayan tek bir aracı olmadığı sürece, sonraki işlerin önceki işlerle aynı aracıyı kullanacağı garantisi yoktur. Daha fazla bilgi için bkz . Talepleri belirtme.

Temiz çalışma alanına ek olarak, işlem hattı ayarları kullanıcı arabiriminde Temizleme ayarını yapılandırarak temizlemeyi de yapılandırabilirsiniz. Temiz ayarı true olduğunda ve bu da varsayılan değeridir, işlem hattınızdaki her kullanıma alma adımı için belirtmeye clean: true eşdeğerdir. belirttiğinizde clean: truegit getirmeden önce komutunu çalıştırırsınız git clean -ffdx git reset --hard HEAD . Temizle ayarını yapılandırmak için:

İşlem hattınızı düzenleyin, ...'yi ve ardından Tetikleyiciler'i seçin.
YAML'yi seçin, Kaynakları alın ve istediğiniz Temiz ayarını yapılandırın. Varsayılan değer true'dur.

Şirket içinde barındırılan bir aracıda işlem hattı çalıştırdığınızda, varsayılan olarak, ardışık iki çalıştırma arasında alt dizinlerin hiçbiri temizlenmez. Sonuç olarak, görevlerin bunu yapmak için uygulanması koşuluyla artımlı derlemeleri ve dağıtımları çalıştırabilirsiniz. Ancak, görev altındaki Get sources seçeneğini kullanarak Clean build bu davranışı geçersiz kılabilirsiniz. Seçenekler, kullandığınız deponun türüne bağlı olarak değişir.

Yapıt indirme

Bu örnek YAML dosyası yapıtı WebSite yayımlar ve ardından yapıtı öğesine $(Pipeline.Workspace)indirir. Dağıtma işi yalnızca Derleme işi başarılı olursa çalışır.

YAML
Klasik

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

dependsOn ve koşul kullanma hakkında bilgi için bkz. Koşulları belirtme.

OAuth belirtecine erişim

bir işte çalışan betiklerin geçerli Azure Pipelines veya TFS OAuth güvenlik belirtecine erişmesine izin vekleyebilirsiniz. Belirteç, Azure Pipelines REST API'sinde kimlik doğrulaması yapmak için kullanılabilir.

YAML
Klasik

OAuth belirteci YAML işlem hatlarında her zaman kullanılabilir. kullanılarak envgöreve veya adıma açıkça eşlenmelidir. Bir örnek aşağıda verilmiştir:

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

Aracılığıyla paylaş