GitHub 작업 및 Maven 버전

나는 GitLab을 매우 좋아한다.그러나 GitHub는 이미 개원 프로젝트를 위탁 관리하는 사실 기준이 되었다.GitHub 작업을 통해 GitHub를 떠나지 않고도 전체 연속 통합 파이핑을 구현할 수 있습니다.
본고에서 저는 GitHub 조작을 사용하여 Maven 공작물을 방출하는 방법을 중점적으로 소개하고 싶습니다.

Maven 선결 조건

CI 파이핑을 생성하고 실행하기 전에 베이스 Maven 프로젝트를 구성할 필요가 있습니다.

스피드 마븐 페인트

Maven은 이 문장보다 더 많은 것을 포괄할 수 있는 매우 큰 주제이다.그러나 이 글의 나머지 부분을 이해하기 위해서는 여기가 가장 중요한 부분이다.
Maven은 다음과 같은 세 가지 고유 좌표계를 통해 항목을 참조합니다.

그룹 ID

가공소재 ID

A 버전

예를 들어, 샘플 항목의 좌표는 다음과 같습니다.

<groupId>ch.frankel.blog.renamer</groupId>
<artifactId>renamer-swing</artifactId>
<version>1.0-SNAPSHOT</version>

프로젝트의 출력은 JAR과 같은 가공소재입니다.-SNAPSHOT 추가 항목의 버전을 사용할 수 있습니다.스냅샷 버전 개발 중;비스냅샷 버전, 일반 버전.
일부 프로젝트는 최종 발표 전에 이정표 및/또는 발표 후보를 제공합니다.이런 상황에서 마븐 자체는 이를 위한 명명 방안을 제공하지 않았다.예를 들어, Spring 프레임워크는 .Mx, .RCx 및 .RELEASE 버전에 첨부됩니다. 이 프레임워크는 스냅샷으로 간주되지 않습니다.

게시 관리

Maven Release plugin 발표 프로세스를 관리합니다.그것은 두 가지 상호 보완 목표prepare와 perform를 제공했다.다음 작업을 수행합니다.
준비:

POM의 버전을 x-SNAPSHOT에서 새 버전으로 변경

POM에서 SCM 정보를 변환하여 레이블을 포함하는 최종 목적지

수정된 POM 제출

SCM의 코드를 버전 이름

으로 표시

POM의 버전을 새 값으로 추가y-SNAPSHOT

수정된 POM 제출

다음을 수행합니다.

옵션 태그

를 사용하여 SCM URL에서 체크 아웃

미리 정의된 Mavendeploy 목표

실행
필요한 SCM 정보에 대해 Maven POM은 전용 섹션을 제공합니다.우리의 견본에 따르면, 그것은 보기에 다음과 같다.

<scm>
  <developerConnection>scm:git:https://github.com/ajavageek/renamer-swing.git</developerConnection>
</scm>

인증

위의 코드 세그먼트는 서로 다른 프로토콜을 사용할 수 있습니다. git, http, https, 심지어 ssh.file 프로토콜을 사용하여 인증을 하려면 SSH 키가 필요합니다.CI 파이핑 환경에서는 이 작업을 수행할 수 없습니다.
따라서 상기 설정 세션은 git 프로토콜을 사용해야 한다.사용자/암호 쌍 형식의 자격 증명이 필요합니다.Maven은 프로젝트에 특정한 데이터를 크로스 프로젝트에서 공유하는 데이터(예를 들어 안전 관련 데이터)와 결합시킨다.POM은 전자를 담당하고 http 파일은 후자를 책임진다.각 자격 증명 쌍에는 고유한 식별자가 필요합니다.

<settings>
  <servers>
    <server>
      <id>github</id>                     <!-- 1 -->
      <username>my_usernam</username>
      <password>my_password</password>
    </server>
  </servers>
</settings>

고유 식별자

특정 항목$HOME/.m2/settings.xml을 사용하도록 Maven 항목을 구성하려면 server 키와 서버의 project.scm.id 속성을 추가합니다.

<properties>
  <project.scm.id>github</project.scm.id>  <!-- 1 -->
</properties>

프로젝트는 설정 파일

에 구성된 id 서버에 사용됩니다.

판매 관리

Maven의 저자는 플러그인 구조를 둘러싸고 Maven을 설계했다.Maven 자체는 하나의 구축 생명주기만 제공하고 하나의 구축 단계를 포함한다.Maven 엔진은 순서대로 각 단계를 호출한다.초기 단계를 거치지 않으면 순환은 후기에 들어갈 수 없다.예를 들어 구축 라이프 사이클의 단계는 github, compile, test, integration-test, package 및 deploy 입니다.test 첫 번째 운행compile이 없는 상태에서 운행할 수 없습니다.
플러그인 대상을 특정 단계에 연결할 수 있습니다.기본적으로 Maven은 몇 개의 목표를 연결합니다.예를 들어 package 단계 귀속maven-jar-plugin:jar 목표.달리기mvn package는 모든 단계의 모든 목표 경계를 순서대로 실행한다package.
호출 release:perform 목표는 Maven fork를 시작하여 실행 deploy 단계를 시작합니다.기본적으로 Maven은 Maven 배치 플러그인deploy:deploy 목표를 deploy에 연결합니다.이것은 마븐이 package 단계에 귀속된 목표를 실행했다는 것을 의미한다.따라서 구축 부품은 deploy 시작 시 사용할 수 있다.배치는 마ven이 현식 설정이 필요한 등록표에 공작물을 밀어 넣는 것을 의미한다.
이 프로젝트의 상하문에서 공작물은 JAR이고 등록표는 GitHub이다.그러면 다음 구성 세션으로 변환됩니다.

<distributionManagement>
  <repository>
    <id>github</id>
    <name>GitHub</name>
    <url>https://maven.pkg.github.com/ajavageek/renamer-swing</url>  <!-- 1 -->
  </repository>
</distributionManagement>

GitHub 레지스트리의 루트 위치https://maven.pkg.github.com

Maven 명령

실행해야 할 release:prepare 및 release:perform 목표를 구축합니다.
기본적으로 release:prepare 는 대화식입니다. 플러그인은 버전과 새 스냅샷 버전을 발표해야 합니다.자동 구축에 대해서는 불가능하다.
명령행-B 플래그를 사용하여 일괄 처리 모드에서 Maven을 실행할 수 있습니다.이 경우 플러그인은 자동으로 릴리즈 버전과 스냅샷 버전을 추정합니다.
명령은 다음과 같이 변경됩니다.

mvn -B release:prepare release:perform

Maven 패키지

마지막 준비 절차는 마븐 버전과 완전히 독립하는 것이다.
앞으로 프로젝트를 구축하는 데 사용할 특정 Maven 버전은 더 이상 사용할 수 없을 것입니다.당시에 사용할 수 있는 버전은 그것과 호환되지 않을 수도 있다.따라서 Maven 플러그인은 패키지를 제공합니다.패키지는 환경에 관계없이 JAR을 실행합니다. mvn 도구의 특정 버전을 시작할 수 있습니다.이러한 패키지를 만드는 것은 간단합니다.

mvn -N io.takari:maven:wrapper

이것은 프로젝트 내에 .mvn 폴더를 포함한 두 개의 파일을 만들 것입니다.SCM에 이러한 파일을 모두 추가해야 합니다.
이 점에서부터 mvn 명령을 사용하지 않고 프로젝트 루트 디렉터리에 있는 mvnw 스크립트를 사용해야 합니다.구축에는 더 이상 로컬 Maven 설치가 필요하지 않습니다.

GitHub에서 구축

이제 POM을 구성했습니다. Maven을 GitHub 구축에 통합할 때가 되었습니다.
이 생각은 두 가지가 있다. master과release.GitHub는 분기에 제출될 때마다 새 버전과 배포를 작성해야 합니다.나중에 수동 단계에서 release 및 master 분기의 기본/결합을 재설정할 수 있습니다.release 목표가 실제로 표시를 만들었다는 것을 기억하십시오.대체 방안으로 마ven을 기본 흐름을 반전시켜 표시된 구축을 촉발하고 지점으로 전송할 수 있습니다.

GitHub 작업 소개

기존 CI 도구는 저장소 루트 디렉토리에 저장된 구성 파일을 사용합니다.
도구
파일
젠킨스release:prepareGitLab 회사Jenkinsfile트래비스 CI.gitlab-ci.ymlGitHub 작업은 유사한 방법을 따르지만 두 가지 중요한 차이점은 다음과 같습니다.

이 프로젝트는 여러 개의 구축 파일, 즉 작업 흐름을 사용할 수 있다

폴더.travis.yml에 있어야 합니다.

구축 단계

첫 번째 단계는 분명히 환매를 검사하는 것이다.

- name: Checkout project
  uses: actions/checkout@v2

다음은 JDK 설치:

- name: Setup Java JDK
  uses: actions/[email protected]
  with:
    java-version: 14                    # 1
    server-id: github                   # 2

Java 14 설치

Maven$PROJECT_ROOT/.github/workflows 파일과 다음 값이 구성된 서버를 만듭니다.

settings.xml : id

github: 구축을 시작한 사용자

username : password

나는 $GITHUB_TOKEN 파일을 만드는 작업을 찾는 데 많은 시간을 들였다.settings.xml 조작은 사실상 이 점을 실현하는 가장 간단한 방법이다.Java만 구성하는 것이 아닙니다.setup-java 실제로는 release:prepare 사용자와 전자 메일을 구성할 필요가 있습니다.

- name: Configure Git user
  run: |
    git config user.email "[email protected]"
    git config user.name "GitHub Actions"

마지막 단계는 사실상 가장 간단하다.
위에서 Maven 명령을 실행하기만 하면 됩니다.

- name: Publish JAR
  run: ./mvnw -B release:prepare release:perform
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}     #1

commit 파일에서 찾은 자격 증명을 사용하지만 GitHub 작업을 통해 release:prepare 환경 변수 값을 사용합니다.

개념 증명

settings.xml 분기가 방출될 준비가 되면 deploy:deploy 분기로 밀어내기만 하면 됩니다.

git push origin master:release

이것은 촉발할 것이다workflow.

워크플로우의 성공적인 실행으로 게시, 태그 및 배포가 생성되었습니다.

최종 Git 그림은 다음과 같습니다.

결론

GitHub 작업을 사용하여 Maven 버전을 관리하는 것은 쉽지 않습니다.그러나 이것은 단지 약간의 경험만 있으면 실현할 수 있다.저는 이 글이 이런 체험을 제공함으로써 Maven 사용자들이 GitHub 조작의 힘을 충분히 이용하도록 도와줄 수 있기를 바랍니다.
더 나아가서:

Maven Release Plugin

Maven Deploy Plugin

Publishing Java packages with Maven

Setup Java JDK GitHub Action

원본은 2020년 8월 30일A Java Geek