- 설치
- 업데이트
- 설치 제거
-
Windows 문제 해결
- 러너 로그 가져오기
- Windows 빌드 중 PathTooLongException 발생
- Windows BASH 스크립트 실행할 수 없음;
The system cannot find the batch label specified - buildscript오류 발생 - 웹 터미널에서 색이 칠해진 출력을 얻으려면?
- 서비스 시작 시
The service did not start due to a logon failure오류 발생 - Kubernetes executor를 사용하여 작업이 성공으로 표시되었지만 중간에 종료됨
- Docker executor:
unsupported Windows Version - Kubernetes executor:
unsupported Windows Version - 매핑된 네트워크 드라이브를 사용하고 빌드에서 올바른 경로를 찾을 수 없음
- 빌드 컨테이너가 서비스 컨테이너에 연결할 수 없음
- 작업이 빌드 디렉터리를 생성하지 못하고 오류로 실패함
- Windows Subsystem for Linux (WSL)의 표준 출력에 대한 공백 줄이 작업 로그에 표시됨
Windows에서 GitLab Runner 설치
Windows에서 GitLab Runner를 설치하고 실행하려면 다음이 필요합니다.
- 공식 사이트에서 설치할 수 있는 Git
- 내장 시스템 계정이 아닌 사용자 계정으로 실행하려면 사용자 계정의 암호가 필요합니다.
설치
gitlab-runner로 이름이 변경되었습니다.- 시스템의 원하는 곳에 폴더를 만듭니다. 예:
C:\GitLab-Runner. -
64비트 또는 32비트 바이너리를 다운로드하여 만든 폴더에 넣습니다. 다음은 선택 사항이지만, 바이너리의 이름을
gitlab-runner.exe로 변경했다고 가정합니다. 다른 버전의 바이너리는 Bleeding Edge - 다른 태그 릴리스 다운로드에 설명된 대로 다운로드할 수 있습니다. - GitLab Runner 디렉터리와 실행 파일에 대한 쓰기 권한을 제한해야 합니다. 이러한 권한을 설정하지 않으면 일반 사용자가 실행 파일을 자신의 것으로 바꾸고 권한 상승된 권한으로 임의의 코드를 실행할 수 있습니다.
- 관리 권한 명령 프롬프트를 실행합니다.
- 러너(runner) 등록.
-
GitLab Runner를 서비스로 설치하고 시작합니다. 서비스를 내장 시스템 계정(권장) 또는 사용자 계정을 사용하여 실행할 수 있습니다.
내장 시스템 계정 사용하여 서비스 실행 (위에서 만든 디렉터리 내, 예:
C:\GitLab-Runner)cd C:\GitLab-Runner .\gitlab-runner.exe install .\gitlab-runner.exe start사용자 계정 사용하여 서비스 실행 (위에서 만든 디렉터리 내, 예:
C:\GitLab-Runner)현재 사용자 계정의 유효한 암호를 입력해아 합니다. 왜냐하면 Windows에서 서비스를 시작하는 데 필요하기 때문입니다:
cd C:\GitLab-Runner .\gitlab-runner.exe install --user ENTER-YOUR-USERNAME --password ENTER-YOUR-PASSWORD .\gitlab-runner.exe startGitLab Runner 설치 중에 오류가 발생하는 경우 문제 해결 섹션을 참조하십시오.
- (선택 사항)
C:\GitLab-Runner\config.toml의 러너concurrent값을 업데이트하여 고급 구성 세부 정보에 설명된대로 여러 동시 작업을 허용할 수 있습니다. 추가로, 고급 구성 세부 정보를 사용하여 셸 실행기를 배치가 아닌 Bash 또는 PowerShell로 업데이트할 수 있습니다.
수고하셨습니다! Runner가 설치되었고 실행되며, 각 시스템 재부팅 후에 다시 시작됩니다. 로그는 Windows 이벤트 로그에 저장됩니다.
업데이트
-
서비스를 중지합니다(관리 권한 명령 프롬프트가 필요합니다):
cd C:\GitLab-Runner .\gitlab-runner.exe stop -
64비트 또는 32비트 바이너리를 다운로드하여 러너 실행 파일을 교체합니다. Bleeding Edge - 다른 태그 릴리스 다운로드에 설명된 대로 다른 사용 가능한 버전의 바이너리를 다운로드할 수 있습니다.
-
서비스를 시작합니다:
.\gitlab-runner.exe start
설치 제거
cd C:\GitLab-Runner
.\gitlab-runner.exe stop
.\gitlab-runner.exe uninstall
cd ..
rmdir /s GitLab-Runner
Windows 문제 해결
GitLab Runner의 가장 일반적인 문제에 대해 설명한 FAQ 섹션을 읽었는지 확인하십시오.
계정 이름이 잘못되었다는 오류가 발생하는 경우 사용자 이름 앞에 .\을 추가하십시오:
.\gitlab-runner.exe install --user ".\ENTER-YOUR-USERNAME" --password "ENTER-YOUR-PASSWORD"
서비스를 시작할 때 로그온 실패로 서비스를 시작하지 못했습니다 오류가 발생하는 경우 문제 해결 방법을 확인하려면 FAQ를 참조하십시오.
Windows 암호가 없는 경우 GitLab Runner 서비스를 시작할 수 없지만 내장 시스템 계정을 사용할 수 있습니다.
내장 시스템 계정에 문제가 발생하는 경우 내장 시스템 계정으로 서비스 시작 구성 을 Microsoft의 지원 웹 사이트에서 읽어보십시오.
러너 로그 가져오기
.\gitlab-runner.exe install을 실행하면 gitlab-runner
을 Windows 서비스로 설치합니다. 이벤트 뷰어에서 공급자 이름이 gitlab-runner로 로그를 찾을 수 있습니다.
GUI에 액세스 권한이 없는 경우 PowerShell에서
Get-WinEvent
을 실행할 수 있습니다.
PS C:\> Get-WinEvent -ProviderName gitlab-runner
ProviderName: gitlab-runner
TimeCreated Id LevelDisplayName Message
----------- -- ---------------- -------
2/4/2021 6:20:14 AM 1 Information [session_server].listen_address not defined, session endpoints disabled builds=0...
2/4/2021 6:20:14 AM 1 Information listen_address not defined, metrics & debug endpoints disabled builds=0...
2/4/2021 6:20:14 AM 1 Information Configuration loaded builds=0...
2/4/2021 6:20:14 AM 1 Information Starting multi-runner from C:\config.toml... builds=0...
Windows 빌드 중 PathTooLongException 발생
npm과 같은 도구로 인해 발생하는 문제인데, 때때로 경로가 260자를 초과하는 디렉터리 구조가 생성됩니다. 문제를 해결하는 데 채택할 수 있는 두 가지 가능한 해결책이 있습니다.
a) core.longpaths가 활성화된 Git 사용
먼저 명령줄에서 git config --system core.longpaths true을 실행한 다음, 프로젝트를 GitLab CI 프로젝트 설정 페이지에서 git fetch를 사용하도록 설정하여 디렉터리 구조를 정리하여 문제를 피할 수 있습니다.
b) PowerShell용 NTFSSecurity 도구 사용
PowerShell 모듈인 NTFSSecurity는 긴 경로를 지원하는 Remove-Item2 메서드를 제공합니다. GitLab Runner는 사용 가능하면 이를 감지하고 자동으로 사용합니다.
Windows BASH 스크립트 실행할 수 없음; The system cannot find the batch label specified - buildscript 오류 발생
.gitlab-ci.yml에서 Batch 파일 라인 앞에 call을 추가하여 call C:\path\to\test.bat로 보이도록 해야 합니다.
더 자세한 예제는 다음과 같습니다:
before_script:
- call C:\path\to\test.bat
추가 정보는 이슈 #1025에서 확인할 수 있습니다.
웹 터미널에서 색이 칠해진 출력을 얻으려면?
짧은 답변:
프로그램의 출력에 ANSI 색 코드가 있는지 확인하세요. 텍스트 서식을 위해 UNIX ANSI 터미널 에뮬레이터에서 실행 중이라고 가정합니다(웹UI의 출력이기 때문에).
자세한 답변:
GitLab CI의 웹 인터페이스는 UNIX ANSI 터미널을 흉내냅니다(최소한 부분적으로). gitlab-runner는 빌드에서의 모든 출력을 웹 인터페이스로 바로 보냅니다. 즉, 모든 ANSI 색 코드가 존재한다면 존중받을 것입니다.
Windows의 구버전 CMD 터미널(Windows 10 1511 버전 이전)은 ANSI 색 코드를 지원하지 않습니다. 대신에 win32 (ANSI.SYS) 호출을 사용하는데, 이는 표시할 문자열에 없습니다. 플랫폼 간 프로그램을 작성할 때 개발자는 일반적으로 기본적으로 ANSI 색 코드를 사용하고 Windows 시스템에서 실행될 때 win32 호출로 변환합니다(예: Colorama).
만약 프로그램이 위와 같은 작업을 수행한다면, CI 빌드에서는 ANSI 코드가 문자열에 유지되도록 이 변환을 비활성화해야 합니다.
더 많은 정보는 PowerShell 및 이슈 #332에 대한 예제를 위해 GitLab CI YAML 문서에서 확인할 수 있습니다.
서비스 시작 시 The service did not start due to a logon failure 오류 발생
Windows에서 GitLab Runner 서비스를 설치하고 시작할 때 다음과 같은 오류가 발생할 수 있습니다:
gitlab-runner install --password WINDOWS_MACHINE_PASSWORD
gitlab-runner start
FATA[0000] Failed to start GitLa この場合、サービスを実行するために使用されるユーザーに `SeServiceLogonRight` 권한을 추가해야하며, 그런 다음 서비스를 다시 시작해야합니다.
1. _제어판 > 시스템 및 보안 > 관리 도구_로 이동합니다.
1. _로컬 보안 정책_ 도구를 엽니다.
1. 왼쪽 디렉터리에서 _보안 설정 > 로컬 정책 > 사용자 권한 할당_을 선택합니다.
1. 오른쪽 디렉터리에서 _로그온 유형으로 서비스 로그 온_을 엽니다.
1. _사용자 또는 그룹 추가..._ 버튼을 클릭합니다.
1. 사용자를 추가하고 설정을 적용합니다.
[Microsoft의 문서](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221981(v=ws.11))에 따르면, 이것은 Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012 및 Windows 8에서 작동해야합니다.
_Local Security Policy_ 도구는 일부 Windows 버전에서 사용할 수 없을 수 있습니다 - 예를 들어 각 버전의 "홈 에디션" 변형에서는 사용할 수 없습니다.
서비스 구성에 사용된 사용자에게 `SeServiceLogonRight`를 추가한 후에 `gitlab-runner start` 명령은 오류없이 완료되어야하며 서비스는 정상적으로 시작되어야합니다.
### 작업이 잘못된 성공 또는 실패로 표시됨
대부분의 Windows 프로그램은 성공한 경우 `exit code 0`을 출력합니다. 그러나 일부 프로그램은 종료 코드를 반환하지 않거나 성공에 대한 다른 값이 있습니다. 한 예로 Windows 도구 `robocopy`가 있습니다. 다음의 `.gitlab-ci.yml`은 `robocopy`에 의한 출력으로 성공해야 할지라도 실패합니다.
```yaml
test:
stage: test
script:
- New-Item -type Directory -Path ./source
- New-Item -type Directory -Path ./dest
- Write-Output "Hello World!" > ./source/file.txt
- robocopy ./source ./dest
tags:
- windows
위의 경우, script:에 종료 코드 확인을 매뉴얼으로 추가해야합니다. 예를 들어, PowerShell 스크립트를 만들 수 있습니다.
$exitCodes = 0,1
robocopy ./source ./dest
if ( $exitCodes.Contains($LastExitCode) ) {
exit 0
} else {
exit 1
}
그리고 .gitlab-ci.yml 파일을 다음과 같이 변경해야합니다:
test:
stage: test
script:
- New-Item -type Directory -Path ./source
- New-Item -type Directory -Path ./dest
- Write-Output "Hello World!" > ./source/file.txt
- ./robocopyCommand.ps1
tags:
- windows
또한 PowerShell 함수를 사용할 때 return과 exit의 차이에 주의해야합니다. exit 1은 작업을 실패로 표시하지만, return 1은 하지 않습니다.
Kubernetes executor를 사용하여 작업이 성공으로 표시되었지만 중간에 종료됨
Job 실행을 참조하세요.
Docker executor: unsupported Windows Version
GitLab Runner는 Windows Server의 버전을 확인하여 지원 여부를 확인합니다.
이를 위해 docker info를 실행하여 확인합니다.
만약 GitLab Runner가 다음과 같은 오류로 시작하지 못하는 경우, 그러나 Windows Server 버전이 지정되지 않은 경우, Docker 버전이 너무 오래되었을 가능성이 높습니다.
준비에 실패함: 베이스 이미지 감지: 지원되지 않는 Windows 버전: Windows Server Datacenter
이 오류에는 Windows Server 버전에 대한 자세한 정보가 포함되어 있으며, 이를 GitLab Runner가 지원하는 버전과 비교합니다.
지원되지 않는 Windows Version: Windows Server Datacenter Version (OS Build 18363.720)
Windows Server의 Docker 17.06.2는 docker info의 출력으로 다음을 반환합니다.
Operating System: Windows Server Datacenter
이 경우 문제를 해결하기 위해 Windows Server 릴리스와 유사한 시기의 Docker 버전을 업그레이드하면 됩니다.
Kubernetes executor: unsupported Windows Version
Windows에서 Kubernetes executor가 다음과 같은 오류로 실패할 수 있습니다.
Kubernetes 네임스페이스 사용 중: gitlab-runner
ERROR: 준비에 실패함: 헬퍼 이미지 준비 중: 베이스 이미지 감지: 지원되지 않는 Windows Version:
3초 후에 다시 시도됨 ...
ERROR: 작업 실패 (시스템 오류): 헬퍼 이미지 준비 중: 베이스 이미지 감지: 지원되지 않는 Windows Version:
이를 해결하려면 GitLab Runner 구성 파일의 [runners.kubernetes.node_selector] 섹션에 node.kubernetes.io/windows-build nodeSelector를 추가하십시오. 예를 들어:
[runners.kubernetes.node_selector]
"kubernetes.io/arch" = "amd64"
"kubernetes.io/os" = "windows"
"node.kubernetes.io/windows-build" = "10.0.17763"
매핑된 네트워크 드라이브를 사용하고 빌드에서 올바른 경로를 찾을 수 없음
GitLab Runner가 관리자 계정이 아니라 표준 사용자 계정을 사용하여 실행되고 매핑된 네트워크 드라이브를 사용할 수 없는 경우 지정된 경로를 찾을 수 없음.이라는 오류가 발생합니다. 이는 서비스 로그온 세션을 사용하면 보안을 위해 일부 제한 사항을 생성하므로 발생합니다. 대신 드라이브의 UNC 경로를 사용하십시오.
빌드 컨테이너가 서비스 컨테이너에 연결할 수 없음
Windows 컨테이너와 서비스를 사용하려면:
- 각 작업을 위한 네트워크를 생성하는 네트워킹 모드를 사용합니다.
-
FF_NETWORK_PER_BUILD피처 플래그가 활성화되었는지 확인합니다.
작업이 빌드 디렉터리를 생성하지 못하고 오류로 실패함
GitLab-Runner를 Docker-Windows executor로 사용할 때 작업에 다음과 같은 오류가 발생할 수 있습니다.
fatal: c:/builds/gitlab/test로 이동하지 못함: 허가가 거부됨`
이 오류가 발생하면 Docker 엔진이 C:\Program Data\Docker의 전체 권한을 가진 사용자로 실행되는지 확인하십시오. 올바른 권한이 없으면 일부 작업에서 이 디렉터리에 쓰기를 실패합니다.
Windows에서 Docker 엔진 구성에 대해 자세히 알아보기.
Windows Subsystem for Linux (WSL)의 표준 출력에 대한 공백 줄이 작업 로그에 표시됨
기본적으로 Windows Subsystem for Linux (WSL)의 표준 출력은 UTF8로 인코딩되지 않으며 작업 로그에 공백 줄로 표시됩니다. WSL에 대해 UTF8 인코딩을 강제로 설정하여 표준 출력을 표시하려면 WSL_UTF8 환경 변수를 설정할 수 있습니다.
job:
variables:
WSL_UTF8: "1"
도움말