미리 정의된 변수 사용

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

변수를 사용하면 주요 데이터 비트를 파이프라인의 다양한 부분에 편리하게 가져올 수 있습니다. 사용할 수 있는 미리 정의된 변수 목록입니다. 몇 가지 다른 미리 정의된 변수가 있을 수 있지만 대부분 내부용입니다.

이러한 변수는 시스템에서 자동으로 설정되고 읽기 전용입니다. (예외는 Build.Clean 및 System.Debug입니다.)

YAML 파이프라인에서 미리 정의된 변수를 환경 변수로 참조할 수 있습니다. 예를 들어 변수는 변수 Build.ArtifactStagingDirectoryBUILD_ARTIFACTSTAGINGDIRECTORY가 됩니다.

클래식 파이프라인의 경우 배포 작업에서 릴리스 변수를 사용하여 일반적인 정보(예: 환경 이름, 리소스 그룹 등)를 공유할 수 있습니다.

변수 작업에 대해 자세히 알아봅니다.

팁

부조종사 변수에 대한 도움을 요청할 수 있습니다. 자세한 내용은 변수 사용 예제를 생성하도록 Copilot에 요청하세요.

Build.Clean

빌드 에이전트가 원본을 정리하는 방법을 수정하는 사용되지 않는 변수입니다. 원본을 정리하는 방법을 알아보려면 에이전트에서 로컬 리포지토리 정리를 참조하세요.

System.AccessToken

System.AccessToken 는 실행 중인 빌드에서 사용하는 보안 토큰을 전달하는 특수 변수입니다.

YAML

YAML에서는 변수를 사용하여 파이프라인에 명시적으로 매핑 System.AccessToken 해야 합니다. 단계 또는 작업 수준에서 이 작업을 수행할 수 있습니다. 예를 들어 System.AccessToken 사용하여 컨테이너 레지스트리로 인증할 수 있습니다.

steps:
- task: Docker@2
  inputs:
    command: login
    containerRegistry: '<docker connection>'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

빌드 작업 권한 부여 범위를 사용하기 위한 System.AccessToken 기본 범위를 구성할 수 있습니다.

클래식

스크립트 및 태스크가 작업 수준에서 System.AccessToken에 액세스하도록 허용할 수 있습니다.

1. 작업으로 이동

2. 추가 옵션에서 스크립트가 OAuth 토큰에 액세스하도록 허용 상자를 선택합니다.

또한 이 확인란을 선택하면 스크립트에서 푸시 및 끌어오기를 실행할 수 있도록 자격 증명 집합이 Git에 남습니다.

System.Debug

파이프라인 문제를 디버그하는 자세한 로그를 보려면 이를 정의 System.Debug 하고 설정합니다 true.

1. 파이프라인을 편집하세요.

2. 변수를 선택합니다.

3. 이름 System.Debug 및 값을 사용하여 새 변수를 추가합니다 true.

   

4. 새 변수를 저장합니다.

모든 실행에 대한 자세한 정보 표시 로그를 구성하도록 System.Debug 설정합니다true. 시스템 진단 사용 확인란을 사용하여 단일 실행에 대한 자세한 정보 표시 로그를 구성할 수도 있습니다 .

파이프라인 또는 템플릿에서 변수로 설정할 System.Debugtrue 수도 있습니다.

variables:
  system.debug: 'true'

로 설정System.Debug되면 true 명명 Agent.Diagnostic 된 추가 변수가 .로 true설정됩니다. 이 경우 Agent.Diagnostic 에이전트는 true자체 호스팅 에이전트에 대한 네트워크 문제를 해결하는 데 사용할 수 있는 더 많은 로그를 수집합니다. 자세한 내용은 자체 호스팅 에이전트에 대한 네트워크 진단을 참조하세요.

참고 항목

이 변수는 Agent.Diagnostic 에이전트 v2.200.0 이상에서 사용할 수 있습니다.

자세한 내용은 로그를 검토하여 파이프라인 문제 진단을 참조하세요.

에이전트 변수(DevOps Services)

참고 항목

에이전트 변수를 스크립트의 환경 변수로 사용하고 빌드 작업의 매개 변수로 사용할 수 있습니다. 빌드 번호를 사용자 지정하거나 버전 제어 레이블 또는 태그를 적용하는 데 사용할 수 없습니다.

변수	설명
Agent.BuildDirectory	지정된 빌드 파이프라인에 대한 모든 폴더가 만들어지는 에이전트의 로컬 경로입니다. 이 변수의 값은 .와 같습니다 Pipeline.Workspace. 예: /home/vsts/work/1
Agent.ContainerMapping	YAML의 컨테이너 리소스 이름에서 런타임 시 해당 Docker ID로 매핑합니다. 다음은 표를 따르는 예제입니다.
Agent.HomeDirectory	에이전트가 설치된 디렉터리입니다. 여기에는 에이전트 소프트웨어가 포함됩니다. 예: c:\agent
Agent.Id	에이전트의 ID입니다.
Agent.JobName	실행 중인 작업의 이름입니다. 일반적으로 "작업"이 됩니다. 또는 "__default"이지만 다중 구성 시나리오에서는 구성이 됩니다.
Agent.JobStatus	빌드의 상태입니다. Canceled Failed Succeeded SucceededWithIssues (부분적으로 성공) Skipped (마지막 작업) 환경 변수는 .로 AGENT_JOBSTATUS참조되어야 합니다. 이전 agent.jobstatus 버전에서는 이전 버전과의 호환성을 사용할 수 있습니다.
Agent.MachineName	에이전트가 설치된 컴퓨터의 이름입니다.
Agent.Name	풀에 등록된 에이전트의 이름입니다. 자체 호스팅 에이전트를 사용하는 경우 이 이름은 사용자가 지정합니다. 에이전트를 참조 하세요.
Agent.OS	에이전트 호스트의 운영 체제입니다. 유효한 값은 다음과 같습니다. Windows_NT Darwin Linux 컨테이너에서 실행하는 경우 에이전트 호스트와 컨테이너가 다른 운영 체제를 실행하고 있을 수 있습니다.
Agent.OSArchitecture	에이전트 호스트의 운영 체제 프로세서 아키텍처입니다. 유효한 값은 다음과 같습니다. X86 X64 ARM
Agent.TempDirectory	각 파이프라인 작업 후에 정리되는 임시 폴더입니다. 이 디렉터리가 게시되기 전에 .NET Core CLI 작업과 같은 태스크 에서 테스트 결과와 같은 임시 항목을 보관하는 데 사용됩니다. 예: /home/vsts/work/_temp Ubuntu의 경우
Agent.ToolsDirectory	노드 도구 설치 관리자 및 Python 버전을 사용하여 여러 버전의 도구 간에 전환하는 작업에서 사용하는 디렉터리입니다. 이러한 작업은 후속 빌드 단계에서 사용할 수 있도록 이 디렉터리의 PATH 도구를 추가합니다. 자체 호스팅 에이전트에서 이 디렉터리를 관리하는 방법을 알아봅니다.
Agent.WorkFolder	이 에이전트의 작업 디렉터리입니다. 예: c:\agent_work 참고: 이 디렉터리가 파이프라인 작업(예: 컨테이너에 매핑된 경우)에 의해 쓰기 가능하도록 보장되지 않습니다.

Agent.ContainerMapping의 예:

{
  "one_container": {
    "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190"
  },
  "another_container": {
    "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb"
  }
}

빌드 변수(DevOps Services)

템플릿에서 사용할 수 있는 것으로 표시되지 않은 템플릿에서 변수를 사용하는 경우 변수는 렌더링되지 않습니다. 템플릿의 범위 내에서 해당 값에 액세스할 수 없으므로 변수가 렌더링되지 않습니다.

변수	설명	템플릿에서 사용할 수 있나요?
Build.ArtifactStagingDirectory	대상에 푸시되기 전에 아티팩트가 복사되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\a 이 폴더를 사용하는 일반적인 방법은 파일 복사 및 빌드 아티팩트 게시 작업을 사용하여 빌드 아티팩트를 게시하는 것입니다. 참고: Build.ArtifactStagingDirectory 및 Build.StagingDirectory는 서로 교환할 수 있습니다. 이 디렉터리가 새 빌드 전에 제거되므로 직접 정리할 필요가 없습니다. Azure Pipelines의 아티팩트 참조 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.BuildId	완료된 빌드에 대한 레코드의 ID입니다.	아니요
Build.BuildNumber	완료된 빌드의 이름(실행 번호라고도 함)입니다. 이 값에 포함된 항목을 지정할 수 있습니다. 이 변수의 일반적인 사용은 리포지토리 탭에서 지정하는 레이블 형식의 일부로 만드는 것입니다. 참고: 이 값은 공백 또는 기타 잘못된 레이블 문자를 포함할 수 있습니다. 이러한 경우 레이블 형식이 실패합니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.BuildUri	빌드에 대한 URI입니다. 예: vstfs:///Build/Build/1430 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.BinariesDirectory	컴파일된 이진 파일에 대한 출력 폴더로 사용할 수 있는 에이전트의 로컬 경로입니다. 기본적으로 새 빌드 파이프라인은 이 디렉터리를 정리하도록 설정되지 않습니다. 리포지토리 탭에서 빌드를 정리하도록 정의할 수 있습니다. 예: c:\agent_work\1\b 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.ContainerId	아티팩트용 컨테이너의 ID입니다. 파이프라인에서 아티팩트를 업로드하면 특정 아티팩트 전용 컨테이너에 추가됩니다.	아니요
Build.CronSchedule.DisplayName	displayName 파이프라인 실행을 트리거한 cron 일정입니다. 이 변수는 파이프라인 실행이 YAML 예약 트리거에 의해 트리거되는 경우에만 설정됩니다. 자세한 내용은 schedules.cron 정의 - Build.CronSchedule.DisplayName 변수를 참조 하세요.	예
Build.DefinitionName	빌드 파이프라인의 이름입니다. 참고: 이 값은 공백 또는 기타 잘못된 레이블 문자를 포함할 수 있습니다. 이러한 경우 레이블 형식이 실패합니다.	예
Build.DefinitionVersion	빌드 파이프라인의 버전입니다.	예
Build.QueuedBy	"ID 변수 설정 방법"을 참조하세요. 참고: 이 값은 공백 또는 기타 잘못된 레이블 문자를 포함할 수 있습니다. 이러한 경우 레이블 형식이 실패합니다.	예
Build.QueuedById	"ID 변수 설정 방법"을 참조하세요.	예
Build.Reason	빌드를 실행한 이벤트입니다. Manual: 사용자가 빌드를 수동으로 큐에 대기했습니다. IndividualCI: Git 푸시 또는 TFVC 체크 인에 의해 트리거되는 CI(연속 통합) 입니다. BatchedCI: Git 푸시 또는 TFVC 체크 인에 의해 트리거되는 CI(연속 통합) 와 Batch 변경 내용 이 선택되었습니다. Schedule: 예약된 트리거입니다 . ValidateShelveset: 사용자가 특정 TFVC 선반의 빌드를 수동으로 큐에 대기했습니다. CheckInShelveset: 제어된 체크 인 트리거입니다. PullRequest: 빌드가 필요한 Git 분기 정책에 의해 빌드가 트리거되었습니다. BuildCompletion: 빌드가 다른 빌드에 의해 트리거되었습니다. ResourceTrigger: 빌드가 리소스 트리거 에 의해 트리거되었거나 다른 빌드에 의해 트리거되었습니다. 빌드 파이프라인 트리거를 참조 하고 분기 정책을 사용하여 코드 품질 향상을 참조하세요.	예
Build.Repository.Clean	원본 리포지토리 설정에서 정리를 위해 선택한 값입니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.LocalPath	소스 코드 파일이 다운로드되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\s 기본적으로 새 빌드 파이프라인은 변경된 파일만 업데이트합니다. 리포지토리 탭에서 파일을 다운로드하는 방법을 수정할 수 있습니다. 중요 참고: Git 리포지토리를 하나만 체크 아웃하는 경우 이 경로는 코드의 정확한 경로입니다. 여러 리포지토리를 체크 아웃하는 경우 동작은 다음과 같습니다(Build.SourcesDirectory 변수의 값과 다를 수 있음). 자체(기본) 리포지토리에 대한 체크 아웃 단계에 사용자 지정 체크 아웃 경로가 정의되어 있지 않거나 체크 아웃 경로가 자체 리포지토리의 다중 체크 아웃 기본 경로 $(Pipeline.Workspace)/s/&<RepoName> 인 경우 이 변수의 값은 $(Pipeline.Workspace)/s기본값으로 돌아갑니다. 자체(기본) 리포지토리에 대한 체크 아웃 단계에 사용자 지정 체크 아웃 경로가 정의되어 있고 다중 체크 아웃 기본 경로가 아닌 경우 이 변수는 자체 리포지토리에 대한 정확한 경로를 포함합니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.ID	리포지토리의 고유 식별자입니다. 리포지토리의 이름이 변경되더라도 변경되지 않습니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.Name	트리거 리 포지토리의 이름입니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.Provider	트리거 리 포지토리의 형식입니다. TfsGit: TFS Git 리포지토리 TfsVersionControl: Team Foundation 버전 제어 Git: 외부 서버에서 호스트되는 Git 리포지토리 GitHub Svn: 전복 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.Tfvc.Workspace	리포지토리가 Team Foundation 버전 제어 경우 정의됩니다. 빌드 에이전트에서 사용하는 TFVC 작업 영역 의 이름입니다. 예를 들어 Agent.BuildDirectory가 c:\agent_work\12 있고 Agent.Id 8경우 작업 영역 이름은 다음과 같습니다. ws_12_8 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.Uri	트리거 리포지토리의 URL입니다. 예시: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.RequestedFor	"ID 변수 설정 방법"을 참조하세요. 참고: 이 값은 공백 또는 기타 잘못된 레이블 문자를 포함할 수 있습니다. 이러한 경우 레이블 형식이 실패합니다.	예
Build.RequestedForEmail	"ID 변수 설정 방법"을 참조하세요.	예
Build.RequestedForId	"ID 변수 설정 방법"을 참조하세요.	예
Build.SourceBranch	빌드가 큐에 대기 중인 트리거 리포지토리의 분기입니다. 몇 가지 예: Git 리포지토리 분기: refs/heads/main Git 리포지토리 끌어오기 요청: refs/pull/1/merge TFVC 리포지토리 분기: $/teamproject/main TFVC 리포지토리 제어 체크 인: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC 리포지토리 선반 빌드: myshelveset;username@live.com 파이프라인이 태그에 의해 트리거되는 경우: refs/tags/your-tag-name 이 변수를 빌드 번호 형식으로 사용하면 슬래시 문자(/)가 밑줄 문자 _로 바뀝니다. 참고: TFVC에서 제어된 체크 인 빌드를 실행하거나 수동으로 선반을 빌드하는 경우 이 변수를 빌드 번호 형식으로 사용할 수 없습니다.	예
Build.SourceBranchName	빌드가 큐에 대기 중인 트리거 리포지토리의 분기 이름입니다. Git 리포지토리 분기, 끌어오기 요청 또는 태그: ref의 마지막 경로 세그먼트입니다. 예를 들어 이 값은 refs/heads/main .입니다 main. refs/heads/feature/tools 이 값은 .입니다tools. refs/tags/your-tag-name 이 값은 .입니다your-tag-name. TFVC 리포지토리 분기: 작업 영역에 대한 루트 서버 경로의 마지막 경로 세그먼트입니다. 예를 들어 이 값은 $/teamproject/main .입니다 main. TFVC 리포지토리 게이트 체크 인 또는 선반 빌드는 선반의 이름입니다. 예를 들어 Gated_2016-06-06_05.20.51.4369;username@live.com 또는 myshelveset;username@live.com입니다. 참고: TFVC에서 제어된 체크 인 빌드를 실행하거나 수동으로 선반을 빌드하는 경우 이 변수를 빌드 번호 형식으로 사용할 수 없습니다.	예
Build.SourcesDirectory	소스 코드 파일이 다운로드되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\s 기본적으로 새 빌드 파이프라인은 변경된 파일만 업데이트합니다. 중요 참고: Git 리포지토리를 하나만 체크 아웃하는 경우 이 경로는 코드의 정확한 경로입니다. 여러 리포지토리를 체크 아웃하면 자체(기본) 리포지토리가 다중 체크 아웃 기본 $(Pipeline.Workspace)/s 경로와 다른 사용자 지정 경로로 체크 아웃된 경우에도 기본값$(Pipeline.Workspace)/s/<RepoName>으로 되돌립니다(이 점에서 변수는 Build.Repository.LocalPath 변수의 동작과 다름). 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.SourceVersion	이 빌드에 포함된 트리거 리포지토리의 최신 버전 제어 변경 내용입니다. Git: 커밋 ID입니다. TFVC: 변경 집합입니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	예
Build.SourceVersionMessage	트리거 리포지토리에 대한 커밋 또는 변경 집합의 주석입니다. 메시지를 첫 번째 줄 또는 200자로 자른 다음 더 짧습니다. 커 Build.SourceVersionMessage 밋할 때의 메시지에 Build.SourceVersion 해당합니다. PR 빌드에 대한 커밋은 Build.SourceVersion 병합 커밋입니다(원본 분기의 커밋이 아님). 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. 또한 이 변수는 단계 수준에서만 사용할 수 있으며 작업 또는 단계 수준에서 사용할 수 없습니다(즉, 작업이 시작되고 코드가 체크 아웃될 때까지 메시지가 추출되지 않음). 참고: 이 변수는 TFS 2015.4에서 사용할 수 있습니다. 참고: 빌드가 진행 중인 동안 Batch가 변경되면 Build.SourceVersionMessage 변수는 Bitbucket 리포지토리의 클래식 빌드 파이프라인에서 작동하지 않습니다.	아니요
Build.StagingDirectory	대상에 푸시되기 전에 아티팩트가 복사되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\a 이 폴더를 사용하는 일반적인 방법은 파일 복사 및 빌드 아티팩트 게시 작업을 사용하여 빌드 아티팩트를 게시하는 것입니다. 참고: Build.ArtifactStagingDirectory 및 Build.StagingDirectory는 서로 교환할 수 있습니다. 이 디렉터리가 새 빌드 전에 제거되므로 직접 정리할 필요가 없습니다. Azure Pipelines의 아티팩트 참조 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.Repository.Git.SubmoduleCheckout	리포지토리 탭에서 체크 아웃 하위 모듈에 대해 선택한 값입니다. 여러 리포지토리가 체크 아웃된 상태에서 이 값은 트리거 리포지토리의 설정을 추적합니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요
Build.SourceTfvcShelveset	리포지토리가 Team Foundation 버전 제어 경우 정의됩니다. 제어된 빌드 또는 선반 빌드를 실행하는 경우 빌드하는 선반의 이름으로 설정됩니다. 참고: 이 변수는 빌드 번호 형식의 빌드 사용에 유효하지 않은 값을 생성합니다.	아니요
Build.TriggeredBy.BuildId	빌드가 다른 빌드에 의해 트리거된 경우 이 변수는 트리거 빌드의 BuildID로 설정됩니다. 클래식 파이프라인에서 이 변수는 빌드 완료 트리거에 의해 트리거됩니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. YAML 파이프라인을 사용하여 resources트리거하는 경우 리소스 변수를 대신 사용해야 합니다.	아니요
Build.TriggeredBy.DefinitionId	빌드가 다른 빌드에 의해 트리거된 경우 이 변수는 트리거 빌드의 DefinitionID로 설정됩니다. 클래식 파이프라인에서 이 변수는 빌드 완료 트리거에 의해 트리거됩니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. YAML 파이프라인을 사용하여 resources트리거하는 경우 리소스 변수를 대신 사용해야 합니다.	아니요
Build.TriggeredBy.DefinitionName	빌드가 다른 빌드에 의해 트리거된 경우 이 변수는 트리거 빌드 파이프라인의 이름으로 설정됩니다. 클래식 파이프라인에서 이 변수는 빌드 완료 트리거에 의해 트리거됩니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. YAML 파이프라인을 사용하여 resources트리거하는 경우 리소스 변수를 대신 사용해야 합니다.	아니요
Build.TriggeredBy.BuildNumber	빌드가 다른 빌드에 의해 트리거된 경우 이 변수는 트리거 빌드의 수로 설정됩니다. 클래식 파이프라인에서 이 변수는 빌드 완료 트리거에 의해 트리거됩니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. YAML 파이프라인을 사용하여 resources트리거하는 경우 리소스 변수를 대신 사용해야 합니다.	아니요
Build.TriggeredBy.ProjectID	빌드가 다른 빌드에 의해 트리거된 경우 이 변수는 트리거 빌드를 포함하는 프로젝트의 ID로 설정됩니다. 클래식 파이프라인에서 이 변수는 빌드 완료 트리거에 의해 트리거됩니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다. YAML 파이프라인을 사용하여 resources트리거하는 경우 리소스 변수를 대신 사용해야 합니다.	아니요
Common.TestResultsDirectory	테스트 결과가 생성되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\TestResults 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요

파이프라인 변수(DevOps Services)

변수	설명
Pipeline.Workspace	특정 파이프라인에 대한 작업 영역 디렉터리입니다. 이 변수의 값은 .와 같습니다 Agent.BuildDirectory. 예들 들어 /home/vsts/work/1입니다.

팁

클래식 릴리스 파이프라인을 사용하는 경우 클래식 릴리스 및 아티팩트 변수를 사용하여 파이프라인 전체에서 데이터를 저장하고 액세스할 수 있습니다.

배포 작업 변수(DevOps Services)

이러한 변수는 특정 배포 작업으로 범위가 지정되며 작업 실행 시에만 해결됩니다.

변수	설명
Environment.Name	배포 단계를 실행하고 배포 기록을 기록하기 위해 배포 작업의 대상이 되는 환경의 이름입니다. 예들 들어 smarthotel-dev입니다.
Environment.Id	배포 작업에서 대상으로 하는 환경의 ID입니다. 예들 들어 10입니다.
Environment.ResourceName	배포 단계를 실행하고 배포 기록을 기록하기 위해 배포 작업의 대상이 되는 환경 내의 특정 리소스 이름입니다. 예를 들어 bookings 환경에 smarthotel-dev리소스로 추가된 Kubernetes 네임스페이스입니다.
Environment.ResourceId	배포 단계를 실행하기 위해 배포 작업의 대상이 되는 환경 내의 특정 리소스 ID입니다. 예들 들어 4입니다.
Strategy.Name	배포 전략의 이름: canary, runOnce또는 rolling.
Strategy.CycleName	배포의 현재 주기 이름입니다. PreIteration옵션은 , Iteration또는 PostIteration.

시스템 변수(DevOps Services)

템플릿에서 사용할 수 있는 것으로 표시되지 않은 템플릿에서 변수를 사용하는 경우 변수는 렌더링되지 않습니다. 템플릿의 범위 내에서 해당 값에 액세스할 수 없으므로 변수가 렌더링되지 않습니다.

변수	설명	템플릿에서 사용할 수 있나요?
System.AccessToken	OAuth 토큰을 사용하여 REST API에 액세스합니다. YAML 스크립트에서 System.AccessToken을 사용합니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	예
System.CollectionId	TFS 컬렉션 또는 Azure DevOps 조직의 GUID입니다.	예
System.CollectionUri	TFS 컬렉션 또는 Azure DevOps 조직의 URI입니다. 예: https://dev.azure.com/fabrikamfiber/	예
System.DefaultWorkingDirectory	소스 코드 파일이 다운로드되는 에이전트의 로컬 경로입니다. 예: c:\agent_work\1\s 기본적으로 새 빌드 파이프라인은 변경된 파일만 업데이트합니다. 리포지토리 탭에서 파일을 다운로드하는 방법을 수정할 수 있습니다. 이 변수는 에이전트 범위입니다. 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	예
System.DefinitionId	빌드 파이프라인의 ID입니다.	예
System.HostType	build 파이프라인이 빌드인 경우로 설정합니다. 릴리스의 경우 값은 deployment 배포 그룹 작업, gates 게이트 평가 중 및 release 기타(에이전트 및 에이전트 없는) 작업에 대한 것입니다.	예
System.JobAttempt	이 작업을 처음 시도할 때는 1로 설정하고 작업을 다시 시도할 때마다 증가합니다.	아니요
System.JobDisplayName	작업에 지정된 사람이 읽을 수 있는 이름입니다.	아니요
System.JobId	단일 작업의 단일 시도에 대한 고유 식별자입니다. 값은 현재 파이프라인에 고유합니다.	아니요
System.JobName	일반적으로 종속성을 표현하고 출력 변수에 액세스하는 데 사용되는 작업의 이름입니다.	아니요
System.OidcRequestUri	idToken OIDC(OpenID Connect)를 사용하여 Entra ID로 인증을 위해 생성합니다. 자세히 알아보기.	예
System.PhaseAttempt	이 단계를 처음 시도할 때는 1로 설정하고 작업을 다시 시도할 때마다 증가합니다. 참고: "단계"는 작업의 디자인 타임을 나타내는 대부분 중복 개념입니다(작업이 단계의 런타임 버전인 반면). Azure Pipelines에서 "단계"의 개념을 대부분 제거했습니다. 행렬 및 다중 구성 작업은 "단계"가 여전히 "작업"과 구별되는 유일한 위치입니다. 한 단계에서는 입력에만 다른 여러 작업을 인스턴스화할 수 있습니다.	아니요
System.PhaseDisplayName	한 단계에 지정된 사람이 읽을 수 있는 이름입니다.	아니요
System.PhaseName	일반적으로 종속성을 표현하고 출력 변수에 액세스하는 데 사용되는 작업에 대한 문자열 기반 식별자입니다.	아니요
System.PlanId	단일 파이프라인 실행에 대한 문자열 기반 식별자입니다.	아니요
System.PullRequest.IsFork	끌어오기 요청이 리포지토리의 포크에서 가져온 경우 이 변수는 .로 True설정됩니다. 그렇지 않으면 .로 설정됩니다 False.	예
System.PullRequest.PullRequestId	이 빌드를 발생시킨 끌어오기 요청의 ID입니다. 예: 17 (이 변수는 빌드가 />로 인해 실행된 경우에만 초기화됩니다.분기 정책의 영향을 받는 Git PR).	아니요
System.PullRequest.PullRequestNumber	이 빌드를 발생시킨 끌어오기 요청의 수입니다. 이 변수는 다른 끌어오기 요청 ID 및 끌어오기 요청 번호가 있는 GitHub의 끌어오기 요청에 대해 채워집니다. 이 변수는 PR이 분기 정책의 영향을 받는 경우에만 YAML 파이프라인에서 사용할 수 있습니다.	아니요
System.PullRequest.targetBranchName	끌어오기 요청에 대한 대상 분기의 이름입니다. 이 변수는 파이프라인에서 끌어오기 요청의 대상 분기에 따라 태스크 또는 단계를 조건부로 실행하는 데 사용할 수 있습니다. 예를 들어 변경 내용이 병합되는 분기에 따라 다른 테스트 또는 코드 분석 도구 집합을 트리거할 수 있습니다.	아니요
System.PullRequest.SourceBranch	끌어오기 요청에서 검토 중인 분기입니다. 예: refs/heads/users/raisa/new-feature Azure Repos의 경우 (이 변수는 빌드가 />로 인해 실행된 경우에만 초기화됩니다.분기 정책의 영향을 받는 Git PR). 이 변수는 PR이 분기 정책의 영향을 받는 경우에만 YAML 파이프라인에서 사용할 수 있습니다.	아니요
System.PullRequest.SourceCommitId	끌어오기 요청에서 검토 중인 커밋입니다. (이 변수는 빌드가 />로 인해 실행된 경우에만 초기화됩니다.분기 정책의 영향을 받는 Git PR). 이 변수는 PR이 분기 정책의 영향을 받는 경우에만 YAML 파이프라인에서 사용할 수 있습니다.
System.PullRequest.SourceRepositoryURI	끌어오기 요청을 포함하는 리포지토리의 URL입니다. 예: https://dev.azure.com/ouraccount/_git/OurProject	아니요
System.PullRequest.TargetBranch	끌어오기 요청의 대상인 분기입니다. 예를 들어 refs/heads/main 리포지토리가 Azure Repos에 있는 경우 및 main 리포지토리가 GitHub에 있는 경우입니다. 이 변수는 분기 정책의 영향을 받는 Git PR 때문에 빌드가 실행된 경우에만 초기화됩니다. 이 변수는 PR이 분기 정책의 영향을 받는 경우에만 YAML 파이프라인에서 사용할 수 있습니다.	아니요
System.StageAttempt	이 스테이지를 처음 시도할 때는 1로 설정하고 스테이지를 다시 시도할 때마다 증가합니다.	아니요
System.StageDisplayName	스테이지에 지정된 사람이 읽을 수 있는 이름입니다.	아니요
System.StageName	종속성을 표현하고 출력 변수에 액세스하는 데 일반적으로 사용되는 단계의 문자열 기반 식별자입니다.	아니요
System.TeamFoundationCollectionUri	TFS 컬렉션 또는 Azure DevOps 조직의 URI입니다. 예: https://dev.azure.com/fabrikamfiber/ 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	예
System.TeamProject	이 빌드를 포함하는 프로젝트의 이름입니다.	예
System.TeamProjectId	이 빌드가 속한 프로젝트의 ID입니다.	예
System.TimelineId	단일 파이프라인 실행의 실행 세부 정보 및 로그에 대한 문자열 기반 식별자입니다.	아니요
TF_BUILD	True 빌드 태스크에서 스크립트를 실행하는 경우로 설정합니다. 이 변수는 에이전트 범위이며 스크립트의 환경 변수 및 빌드 작업의 매개 변수로 사용할 수 있지만 빌드 번호의 일부 또는 버전 제어 태그로 사용할 수는 없습니다.	아니요

변수 확인(DevOps Services)

변수	설명
Checks.StageAttempt	이 스테이지를 처음 시도할 때는 1로 설정하고 스테이지를 다시 시도할 때마다 증가합니다. 이 변수는 승인 또는 환경 확인 내에서만 사용할 수 있습니다. 예를 들어 REST API 호출 검사 내에서 사용할 $(Checks.StageAttempt) 수 있습니다.

ID 변수는 어떻게 설정합니까?

이 값은 빌드의 원인에 따라 달라지며 Azure Repos 리포지토리와 관련이 있습니다.

빌드가 트리거되는 경우...	그런 다음 Build.QueuedBy 및 Build.QueuedById 값은 다음을 기반으로...	그런 다음 Build.RequestedFor 및 Build.RequestedForId 값은 다음을 기반으로 합니다.
Git 또는 CI(연속 통합) 트리거에서	시스템 ID(예: [DefaultCollection]\Project Collection Service Accounts	변경 내용을 푸시하거나 체크 인한 사람입니다.
Git 또는 분기 정책 빌드에서.	시스템 ID(예: [DefaultCollection]\Project Collection Service Accounts	변경 내용을 체크 인한 사람입니다.
제어된 체크 인 트리거에 의한 TFVC	변경 내용을 체크 인한 사람입니다.	변경 내용을 체크 인한 사람입니다.
Git 또는 TFVC에서 예약된 트리거	시스템 ID(예: [DefaultCollection]\Project Collection Service Accounts	시스템 ID(예: [DefaultCollection]\Project Collection Service Accounts
큐 빌드 단추를 클릭했기 때문입니다.	사용자	사용자

부조종사에게 변수 사용 예제 생성 요청

Copilot 사용하여 변수를 사용하는 파이프라인 조각을 생성합니다. 예를 들어 copilot를 사용하여 Agent.JobStatus 변수를 사용하는 조건으로 스테이지를 생성할 수 있습니다.

다음 텍스트는 Copilot에 대한 예제 프롬프트를 보여줍니다.

Agent.JobStatus Succeeded 또는 SucceededWithIssues경우에만 실행되는 새 Azure DevOps 스테이지를 만들려면 어떻게 해야 하나요?

요구 사항을 충족하는 값을 사용하도록 프롬프트를 사용자 지정할 수 있습니다. 예를 들어 파이프라인이 실패할 때만 실행되는 스테이지를 만드는 데 도움을 요청할 수 있습니다.

참고 항목

GitHub Copilot는 AI를 통해 구동되므로 놀라움과 실수가 가능합니다. 생성된 코드 또는 제안을 확인해야 합니다. GitHub Copilot의 일반적인 사용, 제품 영향, 사용자 감독 및 개인 정보에 대한 자세한 내용은 GitHub Copilot FAQ참조하세요.