- GitLab 패키지 레지스트리에 게시
- 패키지 발행
- 패키지 설치
- Maven 패키지를 위한 CI/CD 통합
- 코드 변경 내용에 따라 조건부 발행
- 코드 품질 및 보안 스캔과의 통합
- 문제 해결
패키지 레지스트리의 Maven 패키지
Tier: Free, Premium, Ultimate
Offering: GitLab.com, Self-managed, GitLab Dedicated
프로젝트의 패키지 레지스트리에 Maven 아티팩트를 게시합니다.
그런 다음, 필요할 때마다 종속성으로 사용하려면 패키지를 설치하세요.
Maven 패키지 관리자 클라이언트가 사용하는 특정 API 엔드포인트에 대한 설명을 보려면 Maven API 문서를 참조하세요.
지원되는 클라이언트:
GitLab 패키지 레지스트리에 게시
패키지 레지스트리에 인증
패키지를 게시하려면 토큰이 필요합니다. 달성하려는 목표에 따라 사용 가능한 다양한 토큰이 있습니다. 자세한 내용은 토큰 안내를 참조하세요.
토큰을 생성하고 나중에 사용하도록 저장하세요.
문서화되지 않은 인증 방법을 사용하지 마세요. 문서화되지 않은 인증 방법은 향후에 제거될 수 있습니다.
클라이언트 구성 편집
구성을 업데이트하여 HTTP를 통해 Maven 저장소에 인증합니다.
사용자 정의 HTTP 헤더
클라이언트의 구성 파일에 인증 세부 정보를 추가해야 합니다.
mvn
토큰 유형 | 이름은 | 토큰 |
---|---|---|
개인 액세스 토큰 | Private-Token
| 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
배포 토큰 | Deploy-Token
| 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
CI 작업 토큰 | Job-Token
| ${CI_JOB_TOKEN}
|
참고:
<name>
필드는 선택한 토큰과 일치하도록 명명되어야 합니다.
다음 섹션을 settings.xml
파일에 추가합니다.
<settings>
<servers>
<server>
<id>gitlab-maven</id>
<configuration>
<httpHeaders>
<property>
<name>REPLACE_WITH_NAME</name>
<value>REPLACE_WITH_TOKEN</value>
</property>
</httpHeaders>
</configuration>
</server>
</servers>
</settings>
gradle
토큰 유형 | 이름은 | 토큰 |
---|---|---|
개인 액세스 토큰 | Private-Token
| 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
배포 토큰 | Deploy-Token
| 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
CI 작업 토큰 | Job-Token
| System.getenv("CI_JOB_TOKEN")
|
참고:
<name>
필드는 선택한 토큰과 일치하도록 명명되어야 합니다.
귀하의 GRADLE_USER_HOME
디렉토리에 다음 내용의 gradle.properties
파일을 만듭니다.
gitLabPrivateToken=REPLACE_WITH_YOUR_TOKEN
귀하의 build.gradle
파일에 repositories
섹션을 추가합니다:
-
Groovy DSL에서:
repositories { maven { url "https://gitlab.example.com/api/v4/groups/<group>/-/packages/maven" name "GitLab" credentials(HttpHeaderCredentials) { name = 'REPLACE_WITH_NAME' value = gitLabPrivateToken } authentication { header(HttpHeaderAuthentication) } } }
-
Kotlin DSL에서:
repositories { maven { url = uri("https://gitlab.example.com/api/v4/groups/<group>/-/packages/maven") name = "GitLab" credentials(HttpHeaderCredentials::class) { name = "REPLACE_WITH_NAME" value = findProperty("gitLabPrivateToken") as String? } authentication { create("header", HttpHeaderAuthentication::class) } } }
기본 HTTP 인증
Maven 패키지 레지스트리에 인증하기 위해 기본 HTTP 인증을 사용할 수도 있습니다.
mvn
토큰 유형 | 이름은 | 토큰 |
---|---|---|
개인 액세스 토큰 | 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
배포 토큰 | 배포 토큰 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
CI 작업 토큰 | gitlab-ci-token
| ${CI_JOB_TOKEN}
|
다음 섹션을 settings.xml
파일에 추가합니다.
<settings>
<servers>
<server>
<id>gitlab-maven</id>
<username>REPLACE_WITH_NAME</username>
<password>REPLACE_WITH_TOKEN</password>
<configuration>
<authenticationInfo>
<userName>REPLACE_WITH_NAME</userName>
<password>REPLACE_WITH_TOKEN</password>
</authenticationInfo>
</configuration>
</server>
</servers>
</settings>
gradle
토큰 유형 | 이름은 | 토큰 |
---|---|---|
개인 액세스 토큰 | 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
배포 토큰 | 배포 토큰 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
CI 작업 토큰 | gitlab-ci-token
| System.getenv("CI_JOB_TOKEN")
|
귀하의 GRADLE_USER_HOME
디렉토리에 다음 내용의 gradle.properties
파일을 만듭니다.
gitLabPrivateToken=REPLACE_WITH_YOUR_TOKEN
귀하의 build.gradle
파일에 repositories
섹션을 추가합니다:
-
Groovy DSL에서:
repositories { maven { url "https://gitlab.example.com/api/v4/groups/<group>/-/packages/maven" name "GitLab" credentials(PasswordCredentials) { username = 'REPLACE_WITH_NAME' password = gitLabPrivateToken } authentication { basic(BasicAuthentication) } } }
-
Kotlin DSL에서:
repositories { maven { url = uri("https://gitlab.example.com/api/v4/groups/<group>/-/packages/maven") name = "GitLab" credentials(BasicAuthentication::class) { username = "REPLACE_WITH_NAME" password = findProperty("gitLabPrivateToken") as String? } authentication { create("basic", BasicAuthentication::class) } } }
sbt
토큰 유형 | 이름은 | 토큰 |
---|---|---|
개인 액세스 토큰 | 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
배포 토큰 | 배포 토큰 사용자의 사용자 이름 | 토큰을 그대로 붙여넣기하거나 토큰을 보유하도록 환경 변수를 정의하세요 |
CI 작업 토큰 | gitlab-ci-token
| sys.env.get("CI_JOB_TOKEN").get
|
SBT의 인증은 기본 HTTP 인증에 기반합니다. 이름과 암호를 제공해야 합니다.
참고:
이름 필드는 선택한 토큰과 일치하도록 명명되어야 합니다.
sbt
를 사용하여 Maven GitLab 패키지 레지스트리에서 패키지를 설치하려면 Maven resolver를 구성해야 합니다. 비공개 또는 내부 프로젝트나 그룹에 액세스하는 경우 자격 증명을 설정해야 합니다. 리졸버 및 인증을 구성한 후 프로젝트, 그룹 또는 네임스페이스에서 패키지를 설치할 수 있습니다.
귀하의 build.sbt
에 다음과 같은 내용을 추가합니다:
resolvers += ("gitlab" at "<endpoint url>")
credentials += Credentials("GitLab Packages Registry", "<host>", "<name>", "<token>")
이 예에서:
-
<endpoint url>
은 엔드포인트 URL입니다.
예:https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven
. -
<host>
는 프로토콜 스키마나 포트 없이<endpoint url>
에 포함된 호스트입니다.
예:gitlab.example.com
. -
<name>
및<token>
은 위의 표에서 설명된 대로 사용합니다.
명명 규칙
Maven 패키지를 설치하려면 세 가지 엔드포인트 중 하나를 사용할 수 있습니다. 패키지를 프로젝트에 발행해야 하지만 선택한 엔드포인트에 따라 pom.xml
파일에 추가해야 할 설정이 결정됩니다.
세 가지 엔드포인트는 다음과 같습니다:
- 프로젝트 레벨: 이 엔드포인트는 몇 개의 Maven 패키지가 있고 이들이 동일한 GitLab 그룹에 속해 있지 않을 때 사용합니다.
- 그룹 레벨: 이 엔드포인트는 동일한 GitLab 그룹 내의 여러 프로젝트에서 패키지를 설치하려는 경우 사용합니다. GitLab은 그룹 내에서 패키지 이름의 고유성을 보장하지 않습니다. 즉, 동일한 패키지 이름과 버전을 갖는 두 프로젝트를 가질 수 있습니다. 결과적으로 GitLab은 더 최근 버전을 제공합니다.
- 인스턴스 레벨: 이 엔드포인트는 다른 GitLab 그룹이나 고유한 네임스페이스에 많은 패키지가 있는 경우 사용합니다.
인스턴스 레벨 엔드포인트를 사용하는 경우 Maven의 pom.xml
에서 관련 섹션이 다음과 같이 보이도록 합니다:
<groupId>group-slug.subgroup-slug</groupId>
<artifactId>project-slug</artifactId>
프로젝트의 경로와 동일한 패키지만 인스턴스 레벨 엔드포인트에서 노출됩니다.
프로젝트 | 패키지 | 인스턴스 레벨 엔드포인트 사용 가능 |
---|---|---|
foo/bar
| foo/bar/1.0-SNAPSHOT
| 예 |
gitlab-org/gitlab
| foo/bar/1.0-SNAPSHOT
| 아니요 |
gitlab-org/gitlab
| gitlab-org/gitlab/1.0-SNAPSHOT
| 예 |
엔드포인트 URL
엔드포인트 |
pom.xml 을 위한 엔드포인트 URL
| 추가 정보 |
---|---|---|
프로젝트 | https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven
|
gitlab.example.com 을 도메인 이름으로 바꿉니다. <project_id> 는 프로젝트 개요 페이지에서 찾을 수 있는 프로젝트 ID로 교체합니다.
|
그룹 | https://gitlab.example.com/api/v4/groups/<group_id>/-/packages/maven
|
gitlab.example.com 을 도메인 이름으로 바꿉니다. <group_id> 는 그룹의 홈페이지에서 찾을 수 있는 그룹 ID로 교체합니다.
|
인스턴스 | https://gitlab.example.com/api/v4/packages/maven
|
gitlab.example.com 을 도메인 이름으로 바꿉니다.
|
발행용 구성 파일 편집
클라이언트의 구성 파일에 발행 세부 정보를 추가해야 합니다.
mvn
선택한 엔드포인트에 관계 없이 다음이 있어야 합니다:
-
distributionManagement
섹션에 프로젝트별 URL. -
repository
및distributionManagement
섹션.
Maven의 pom.xml
에서 관련 repository
섹션은 다음과 같아야 합니다:
<repositories>
<repository>
<id>gitlab-maven</id>
<url><your_endpoint_url></url>
</repository>
</repositories>
<distributionManagement>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven</url>
</repository>
<snapshotRepository>
<id>gitlab-maven</id>
<url>https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven</url>
</snapshotRepository>
</distributionManagement>
-
id
는settings.xml
에서 정의한 것입니다. -
<your_endpoint_url>
은 선택한 엔드포인트에 따라 다릅니다. -
gitlab.example.com
을 도메인 이름으로 바꿉니다.
gradle
Gradle을 사용하여 패키지를 발행하려면:
-
플러그인 섹션에 Gradle 플러그인
maven-publish
을 추가합니다:-
Groovy DSL에서:
plugins { id 'java' id 'maven-publish' }
-
Kotlin DSL에서:
plugins { java `maven-publish` }
-
-
publishing
섹션을 추가합니다:-
Groovy DSL에서:
publishing { publications { library(MavenPublication) { from components.java } } repositories { maven { url "https://gitlab.example.com/api/v4/projects/<PROJECT_ID>/packages/maven" credentials(HttpHeaderCredentials) { name = "REPLACE_WITH_TOKEN_NAME" value = gitLabPrivateToken // 변수는 $GRADLE_USER_HOME/gradle.properties에 있습니다. } authentication { header(HttpHeaderAuthentication) } } } }
-
Kotlin DSL에서:
publishing { publications { create<MavenPublication>("library") { from(components["java"]) } } repositories { maven { url = uri("https://gitlab.example.com/api/v4/projects/<PROJECT_ID>/packages/maven") credentials(HttpHeaderCredentials::class) { name = "REPLACE_WITH_TOKEN_NAME" value = findProperty("gitLabPrivateToken") as String? // 변수는 $GRADLE_USER_HOME/gradle.properties에 있습니다. } authentication { create("header", HttpHeaderAuthentication::class) } } } }
-
패키지 발행
경고:
DeployAtEnd
옵션을 사용하면 400 bad request {"message":"Validation failed: Name has already been taken"}
과 같은 거부 메시지를 받을 수 있습니다. 자세한 내용은 이슈 424238을 참조하세요.
인증을 설정하고 발행을 위한 엔드포인트를 선택한 후 Maven 패키지를 프로젝트에 발행하세요.
mvn
Maven을 사용하여 패키지를 발행하려면:
mvn deploy
배포가 성공하면 빌드 성공 메시지가 표시됩니다:
...
[INFO] BUILD SUCCESS
...
메시지에는 패키지가 올바른 위치에 발행되었음을 나타내는 정보도 표시되어야 합니다:
Uploading to gitlab-maven: https://example.com/api/v4/projects/PROJECT_ID/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/my-project-1.0-20200128.120857-1.jar
gradle
발행 작업을 실행합니다:
gradle publish
프로젝트의 Packages and registries 페이지로 이동하여 발행된 패키지를 확인합니다.
sbt
build.sbt
파일에서 publishTo
설정을 구성합니다:
publishTo := Some("gitlab" at "<endpoint url>")
자격 증명이 올바르게 참조되는지 확인합니다. 자세한 내용은 sbt
설명서를 참조하세요.
sbt
를 사용하여 패키지를 발행하려면:
sbt publish
배포가 성공하면 빌드 성공 메시지가 표시됩니다:
[success] Total time: 1 s, completed Jan 28, 2020 12:08:57 PM
발행된 패키지가 올바른 위치에 발행되었음을 확인하기 위해 성공 메시지를 확인합니다:
[info] published my-project_2.12 to https://gitlab.example.com/api/v4/projects/PROJECT_ID/packages/maven/com/mycompany/my-project_2.12/0.1.1-SNAPSHOT/my-project_2.12-0.1.1-SNAPSHOT.pom
패키지 설치
GitLab 패키지 레지스트리에서 패키지를 설치하려면 원격 설정 및 인증을 해야 합니다. 이 작업이 완료되면 프로젝트, 그룹 또는 네임스페이스에서 패키지를 설치할 수 있습니다.
동일한 이름과 버전을 가진 여러 패키지가 있는 경우, 패키지를 설치하면 가장 최근에 게시된 패키지가 검색됩니다.
가장 최근에 게시된 패키지를 읽을 수 있는 권한이 부족한 경우 403 Forbidden
이 반환됩니다.
mvn
mvn install
을 사용하여 패키지를 설치하려면:
-
종속성을 수동으로 프로젝트의
pom.xml
파일에 추가합니다. 이전에 만든 예제 추가를 위해 XML은 다음과 같을 것입니다:<dependency> <groupId>com.mycompany.mydepartment</groupId> <artifactId>my-project</artifactId> <version>1.0-SNAPSHOT</version> </dependency>
-
프로젝트에서 다음을 실행합니다:
mvn install
메시지에서 패키지가 패키지 레지스트리에서 다운로드된 것으로 표시됩니다:
Downloading from gitlab-maven: http://gitlab.example.com/api/v4/projects/PROJECT_ID/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/my-project-1.0-20200128.120857-1.pom
Maven dependency:get
명령을 직접 사용하여 패키지를 설치할 수도 있습니다.
-
프로젝트 디렉토리에서 다음을 실행합니다:
mvn dependency:get -Dartifact=com.nickkipling.app:nick-test-app:1.1-SNAPSHOT -DremoteRepositories=gitlab-maven::::<gitlab endpoint url> -s <settings.xml 경로>
참고:
명령어 내의 리포지토리 ID(gitlab-maven
)와 settings.xml
파일은 일치해야 합니다.
메시지에서 패키지가 패키지 레지스트리에서 다운로드된 것으로 표시됩니다:
Downloading from gitlab-maven: http://gitlab.example.com/api/v4/projects/PROJECT_ID/packages/maven/com/mycompany/mydepartment/my-project/1.0-SNAPSHOT/my-project-1.0-20200128.120857-1.pom
gradle
gradle
을 사용하여 패키지를 설치하려면:
-
종속성을
build.gradle
의 종속성 부분에 추가합니다:-
Groovy DSL에서:
dependencies { implementation 'com.mycompany.mydepartment:my-project:1.0-SNAPSHOT' }
-
Kotlin DSL에서:
dependencies { implementation("com.mycompany.mydepartment:my-project:1.0-SNAPSHOT") }
-
-
프로젝트에서 다음을 실행합니다:
gradle install
sbt
sbt
를 사용하여 패키지를 설치하려면:
-
build.sbt
에 인라인 종속성을 추가합니다:libraryDependencies += "com.mycompany.mydepartment" % "my-project" % "8.4"
-
프로젝트에서 다음을 실행합니다:
sbt update
Maven 패키지를 위한 CI/CD 통합
CI/CD를 사용하여 Maven 패키지를 자동으로 빌드, 테스트 및 게시할 수 있습니다. 이 섹션의 예제는 다음과 같은 시나리오를 다룹니다:
- 다중 모듈 프로젝트
- 버전별 릴리스
- 조건부 게시
- 코드 품질 및 보안 스캔과의 통합
이러한 예제를 프로젝트 요구에 맞게 조정하고 결합할 수 있습니다.
프로젝트 요구에 맞추어 Maven 버전, Java 버전 및 기타 구체적인 부분을 적절히 설정하십시오. 또한 GitLab 패키지 레지스트리에 게시하려면 필요한 자격 증명 및 설정을 적절히 구성했는지 확인하십시오.
기본 Maven 패키지 빌드 및 게시
이 예제는 Maven 패키지를 빌드하고 게시하는 파이프라인을 구성합니다:
image: maven:3.8.5-openjdk-17
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- .m2/repository/
- target/
stages:
- build
- test
- publish
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
script:
- mvn $MAVEN_CLI_OPTS test
publish:
stage: publish
script:
- mvn $MAVEN_CLI_OPTS deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"
병렬 작업을 사용하는 다중 모듈 Maven 프로젝트
여러 모듈이 있는 대규모 프로젝트의 경우 병렬 작업을 사용하여 빌드 프로세스를 가속화할 수 있습니다:
image: maven:3.8.5-openjdk-17
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- .m2/repository/
- target/
stages:
- build
- test
- publish
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
parallel:
matrix:
- MODULE: [module1, module2, module3]
script:
- mvn $MAVEN_CLI_OPTS test -pl $MODULE
publish:
stage: publish
script:
- mvn $MAVEN_CLI_OPTS deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"
태그를 사용한 버전별 릴리스
태그를 푸시할 때 버전별 릴리스를 생성하는 예제입니다:
image: maven:3.8.5-openjdk-17
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- .m2/repository/
- target/
stages:
- build
- test
- publish
- release
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
script:
- mvn $MAVEN_CLI_OPTS test
publish:
stage: publish
script:
- mvn $MAVEN_CLI_OPTS deploy
only:
- main
release:
stage: release
script:
- mvn versions:set -DnewVersion=${CI_COMMIT_TAG}
- mvn $MAVEN_CLI_OPTS deploy
rules:
- if: $CI_COMMIT_TAG
이 example은 특정 파일이 변경될 때에만 패키지를 발행합니다:
image: maven:3.8.5-openjdk-17
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
cache:
paths:
- .m2/repository/
- target/
stages:
- build
- test
- publish
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
script:
- mvn $MAVEN_CLI_OPTS test
publish:
stage: publish
script:
- mvn $MAVEN_CLI_OPTS deploy
only:
- main
rules:
- changes:
- pom.xml
- src/**/*
변경 사항에 따른 조건부 게시
이 example은 코드 품질 검사와 보안 스캔을 파이프라인에 통합합니다:
image: maven:3.8.5-openjdk-17
variables:
MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
include:
- template: Security/SAST.gitlab-ci.yml
- template: Code-Quality.gitlab-ci.yml
cache:
paths:
- .m2/repository/
- target/
stages:
- build
- test
- quality
- publish
build:
stage: build
script:
- mvn $MAVEN_CLI_OPTS compile
test:
stage: test
script:
- mvn $MAVEN_CLI_OPTS test
code_quality:
stage: quality
sast:
stage: quality
publish:
stage: publish
script:
- mvn $MAVEN_CLI_OPTS deploy
rules:
- if: $CI_COMMIT_BRANCH == "main"
코드 변경 내용에 따라 조건부 발행
코드 품질 및 보안 스캔과의 통합
유용한 힌트
동일한 이름 또는 버전으로 패키지 발행
동일한 이름과 버전으로 패키지를 발행할 때, 새로운 패키지 파일이 기존 패키지에 추가됩니다. 여전히 UI 또는 API를 사용하여 기존 패키지의 이전 자산에 액세스하고 볼 수 있습니다.
이전 패키지 버전을 삭제하려면 패키지 API 또는 UI를 사용하는 것을 고려해보세요.
중복 Maven 패키지를 허용하지 않음
사용자가 중복된 Maven 패키지를 발행하는 것을 방지하려면 GraphQl API 또는 UI를 사용할 수 있습니다.
UI에서:
- 왼쪽 사이드바에서 찾아보기 또는 이동하여를 선택하고 그룹을 찾습니다.
- 설정 > 패키지 및 레지스트리를 선택합니다.
- Maven 행에서 중복 패키지 허용 토글을 끕니다.
- 선택 사항. 예외 텍스트 상자에 허용할 패키지의 이름과 버전과 일치하는 정규식을 입력합니다.
변경 사항이 자동으로 저장됩니다.
Maven 중앙으로의 요청 전달
- Required role changed from Maintainer to Owner in GitLab 17.0.
maven_central_request_forwarding
을 활성화할 수 있습니다.
이 기능은 GitLab.com 또는 GitLab Dedicated 사용자에는 사용할 수 없습니다.Maven 패키지 레지스트리에서 Maven 패키지를 찾을 수 없을 때, 해당 요청은 Maven Central로 전달됩니다.
기능 플래그가 활성화된 경우, administrator는 이 동작을 지속적 통합 설정에서 비활성화할 수 있습니다.
Maven 전달은 프로젝트 수준 및 그룹 수준 endpoints으로 제한됩니다. 인스턴스 수준 endpoint는 해당 규칙을 따르지 않는 패키지에 대해 사용할 수 없을 뿐만 아니라 공급망 스타일 공격에 너무 많은 보안 위험을 유발합니다.
mvn
의 추가 구성
mvn
을 사용할 때 Maven 프로젝트를 구성하여 GitLab에서 Maven Central에 패키지를 요청하는 여러 가지 방법이 있습니다. Maven 저장소는
특정한 순서로 쿼리됩니다.
기본적으로 Maven Central은 보통 처음에 Super POM을 통해 확인됩니다. 따라서 Maven Central 전에 GitLab이 쿼리되도록 GitLab을 구성해야 합니다.
모든 패키지 요청이 Maven Central이 아닌 GitLab으로 전송되도록 하려면 settings.xml
에 <mirror>
섹션을 추가해 Maven Central을 중앙 저장소로 덮어쓸 수 있습니다:
<settings>
<servers>
<server>
<id>central-proxy</id>
<configuration>
<httpHeaders>
<property>
<name>Private-Token</name>
<value><personal_access_token></value>
</property>
</httpHeaders>
</configuration>
</server>
</servers>
<mirrors>
<mirror>
<id>central-proxy</id>
<name>GitLab proxy of central repo</name>
<url>https://gitlab.example.com/api/v4/projects/<project_id>/packages/maven</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>
</settings>
GitLab CI/CD를 사용하여 Maven 패키지 생성
Repository를 Maven 패키지 저장소 사용하도록 구성한 후, GitLab CI/CD를 자동으로 새 패키지 생성하도록 설정할 수 있습니다.
mvn
기본 브랜치가 업데이트될 때마다 새 패키지를 만들 수 있습니다.
-
Maven의
settings.xml
파일로 사용되는ci_settings.xml
파일을 생성합니다. -
pom.xml
파일에서 정의한 것과 동일한 ID를 사용하여server
섹션을 추가합니다. 예를 들어,gitlab-maven
을 ID로 사용합니다:<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd"> <servers> <server> <id>gitlab-maven</id> <configuration> <httpHeaders> <property> <name>Job-Token</name> <value>${CI_JOB_TOKEN}</value> </property> </httpHeaders> </configuration> </server> </servers> </settings>
-
다음을
pom.xml
파일에 포함시킵니다. 이 예에서는 Maven이 미리 정의된 CI/CD 변수들을 사용하도록 허용합니다. 또는 서버의 호스트 이름과 프로젝트 ID를 직접 입력할 수 있습니다.<repositories> <repository> <id>gitlab-maven</id> <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url> </repository> </repositories> <distributionManagement> <repository> <id>gitlab-maven</id> <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url> </repository> <snapshotRepository> <id>gitlab-maven</id> <url>${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/maven</url> </snapshotRepository> </distributionManagement>
-
.gitlab-ci.yml
파일에deploy
작업을 추가합니다:deploy: image: maven:3.6-jdk-11 script: - 'mvn deploy -s ci_settings.xml' rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
-
이러한 파일들을 Repository에 푸시합니다.
다음으로 deploy
작업이 실행되면, ci_settings.xml
이 사용자의 홈 위치에 복사됩니다.
이 예에서는:
- 작업이 Docker 컨테이너에서 실행되므로 사용자는
root
입니다. - Maven은 구성된 CI/CD 변수를 사용합니다.
gradle
기본 브랜치가 업데이트될 때마다 패키지를 만들 수 있습니다.
-
.gitlab-ci.yml
파일에deploy
작업을 추가합니다:deploy: image: gradle:6.5-jdk11 script: - 'gradle publish' rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
-
Repository에 파일을 커밋합니다.
파이프라인이 성공하면 Maven 패키지가 생성됩니다. ::EndTabs ```
버전 유효성 검사
다음 정규식을 사용하여 버전 문자열을 유효성 검사합니다.
\A(?!.*\.\.)[\w+.-]+\z
이 정규식으로 자신의 버전 문자열을 실험해 보고 싶다면, 이 정규식 편집기를 사용해 보세요.
스냅샷 및 릴리스 배포에 대한 다른 설정 사용
스냅샷 및 릴리스용으로 다른 URL 또는 설정을 사용하려면:
-
pom.xml
파일의<distributionManagement>
섹션에 별도의<repository>
및<snapshotRepository>
엘리먼트를 정의합니다.
유용한 Maven 명령줄 옵션
GitLab CI/CD 작업 시 사용할 수 있는 Maven 명령줄 옵션이 있습니다.
-
파일 전송 진행률은 CI 로그를 읽기 어렵게 만들 수 있습니다. 다음과 같은 옵션
-ntp,--no-transfer-progress
이 3.6.1에 추가되었습니다. 또는-B,--batch-mode
또는 로깅 수준 변경을 살펴보세요. -
pom.xml
파일의 위치를 지정할 때 (-f,--file
):package: script: - 'mvn --no-transfer-progress -f helloworld/pom.xml package'
-
사용자 설정 파일의 위치를 지정할 때 (
-s,--settings
) 기본 위치 대신 사용합니다.-gs,--global-settings
옵션도 있습니다:package: script: - 'mvn -s settings/ci.xml package'
지원되는 CLI 명령
GitLab Maven 저장소는 다음 CLI 명령을 지원합니다:
::Tabs
mvn
-
mvn deploy
: 패키지를 패키지 레지스트리에 발행합니다. -
mvn install
: Maven 프로젝트에서 지정된 패키지를 설치합니다. -
mvn dependency:get
: 특정 패키지를 설치합니다.
gradle
-
gradle publish
: 패키지를 패키지 레지스트리에 발행합니다. -
gradle install
: Gradle 프로젝트에서 지정된 패키지를 설치합니다.
문제 해결
GitLab에서 Maven 패키지 작업 중 문제가 발생할 수 있습니다. 많은 일반적인 문제를 해결하려면 다음 단계를 수행해 보세요:
- 인증 확인 - 인증 토큰이 올바르며 만료되지 않았는지 확인합니다.
- 권한 확인 - 패키지를 발행하거나 설치하기 위한 필요한 권한이 있는지 확인합니다.
- Maven 설정 유효성 검사 - 올바른 구성을 위해
settings.xml
파일을 다시 확인합니다. - GitLab CI/CD 로그 검토 - CI/CD 문제의 경우 오류 메시지를 주의 깊게 검토합니다.
- 올바른 엔드포인트 URL 확인 - 프로젝트 또는 그룹에 올바른 엔드포인트 URL을 사용하고 있는지 확인합니다.
-
mvn
명령에-s
옵션 사용 - 항상 Maven 명령을-s
옵션과 함께 실행하세요. 예를 들어,mvn package -s settings.xml
. 이 옵션을 사용하지 않으면 인증 설정이 적용되지 않을 수 있고 Maven이 패키지를 찾지 못할 수 있습니다.
캐시 지우기
성능을 개선하기 위해 클라이언트는 패키지와 관련된 파일을 캐시합니다. 문제가 발생하면 다음 명령을 사용하여 캐시를 지울 수 있습니다:
mvn
rm -rf ~/.m2/repository
gradle
rm -rf ~/.gradle/caches # 또는 사용자 정의 GRADLE_USER_HOME으로 ~/.gradle을 대체하세요
네트워크 추적 로그 검토
Maven 저장소에서 문제가 발생하면 네트워크 추적 로그를 확인해야 할 수 있습니다.
예를 들어 로컬에서 PAT 토큰을 사용하여 mvn deploy
을 실행해 보고 다음 옵션을 사용하세요:
mvn deploy \
-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=trace \
-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=trace
경고: 이러한 옵션을 설정하면 모든 네트워크 요청이 로그에 기록되며 많은 양의 출력이 생성됩니다.
Maven 설정 확인
settings.xml
파일과 관련된 CI/CD에서 문제가 발생하는 경우 유효한 설정을 확인하기 위해 추가 스크립트 작업이나 작업을 추가해 보세요.
도움 플러그인은 시스템 속성을 제공할 수도 있습니다:
mvn-settings:
script:
- 'mvn help:effective-settings'
package:
script:
- 'mvn help:system'
- 'mvn package'
패키지 발행 시 “401 Unauthorized” 오류
이는 일반적으로 인증 문제를 나타냅니다. 다음 사항을 확인하세요:
- 인증 토큰이 유효하며 만료되지 않았는지 확인합니다.
- 올바른 토큰 유형(개인 액세스 토큰, 배포 토큰 또는 CI 작업 토큰)을 사용 중인지 확인합니다.
- 토큰에 필요한 권한(
api
,read_api
, 또는read_repository
)이 있는지 확인하세요. - Maven 프로젝트의 경우
settings.xml
파일과 함께 mvn 명령에-s
옵션을 사용합니다 (예:mvn deploy -s settings.xml
). 이 옵션을 사용하지 않으면 Maven은settings.xml
파일에서 인증 설정을 적용하지 않아 인가되지 않은 오류가 발생할 수 있습니다.
발행 시 “400 Bad Request” 오류 및 메시지 “Validation failed: Version is invalid”
GitLab은 버전 문자열에 대한 특정 요구 사항이 있습니다. 버전이 다음 형식을 따르는지 확인하세요:
^(?!.*\.\.)(?!.*\.$)[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*(\+[0-9A-Za-z-]+)?$
예를 들어, “1.0.0”, “1.0-SNAPSHOT”, “1.0.0-alpha”는 유효하지만 “1..0” 또는 “1.0.”는 유효하지 않습니다.
패키지를 발행하려고 할 때 “Artifact already exists” 오류
이 오류는 이미 존재하는 패키지 버전을 발행하려고 할 때 발생합니다. 해결 방법:
- 발행 전 패키지 버전을 증가시킵니다.
- SNAPSHOT 버전을 사용하는 경우 구성에서 SNAPSHOT 덮어쓰기를 허용하는지 확인합니다.
UI에 표시되지 않는 발행된 패키지
최근에 패키지를 발행했으면 잠시 후에 표시될 수 있습니다. 그래도 표시되지 않는다면:
- 패키지를 볼 권한이 있는지 확인합니다.
- CI/CD 로그나 Maven 출력을 검토하여 패키지를 성공적으로 발행했는지 확인합니다.
- 올바른 프로젝트 또는 그룹을 확인하세요.
Maven 저장소 종속성 충돌
의존성 충돌은 다음과 같이 해결할 수 있습니다:
-
pom.xml
에서 버전을 명시적으로 정의합니다. - Maven의 의존성 관리 섹션을 사용하여 버전을 제어합니다.
-
exclusions
태그를 사용하여 충돌하는 트랜지티브 종속성을 제외합니다.
“Requested target”에 대한 유효한 인증 경로를 찾을 수 없음 오류
일반적으로 SSL 인증서 문제입니다. 해결 방법:
- JDK가 GitLab 서버의 SSL 인증서를 신뢰하도록 합니다.
- 자체 서명된 인증서를 사용하는 경우, JDK의 신뢰 저장소에 추가합니다.
- 마지막 수단으로 Maven 설정에서 SSL 검증을 비활성화할 수 있습니다. 상용 환경에서 권장하지 않습니다.
“접두사에 대한 플러그인을 찾을 수 없음” 파이프라인 오류
보통 Maven이 플러그인을 찾지 못하는 것입니다. 해결 방법:
-
pom.xml
에서 플러그인이 올바르게 정의되었는지 확인합니다. - CI/CD 구성이 올바른 Maven 설정 파일을 사용하는지 확인합니다.
- 파이프라인이 필요한 모든 저장소에 액세스할 수 있는지 확인합니다.