GitHub Actions를 사용한 지옥의 원(자바 프로젝트용 CI/CD 파이프라인 구축)

Java로 프로젝트를 빌드하기 위해 파이프라인을 구축해야 하는 경우가 많습니다. 오픈 소스인 경우도 있고 그렇지 않은 경우도 있습니다. 나는 최근 Travis-CI와 TeamCity에서 GitHub Actions로 내 리포지토리 중 일부를 이동하기로 결정했고 이것이 결과였습니다.

우리는 무엇을 자동화할 것인가?

먼저 자동화할 프로젝트가 필요합니다. Spring boot/Java 11/Maven에서 작은 애플리케이션을 만들어 보겠습니다. 이 기사의 목적에 따라 우리는 애플리케이션 로직에 전혀 관심을 두지 않을 것입니다. 애플리케이션 주변의 인프라는 우리에게 중요하므로 간단한 REST API 컨트롤러이면 충분합니다.

여기에서 소스를 볼 수 있습니다: github.com/antkorwin/github-actions 파이프라인 구축의 모든 단계는 이 프로젝트의 풀 요청에 반영됩니다.

JIRA 및 계획

우리는 일반적으로 JIRA를 이슈 추적기로 사용하므로 이 프로젝트에 대한 별도의 보드를 만들고 거기에 첫 번째 이슈를 추가해 보겠습니다.

잠시 후에 JIRA와 GitHub를 결합하여 어떤 흥미로운 기능을 제공할 수 있는지 다시 살펴보겠습니다.

우리는 프로젝트 조립을 자동화합니다

우리의 테스트 프로젝트는 maven을 통해 구축되었으므로 구축이 매우 간단합니다. 필요한 것은 mvn clean 패키지뿐입니다.

Github Actions를 사용하여 이를 수행하려면 작업 흐름을 설명하는 저장소에 파일을 생성해야 합니다. 이는 일반 yml 파일로 수행할 수 있습니다. "yml 프로그래밍"을 좋아한다고 말할 수는 없지만 무엇을 할 수 있습니까? .github/ 디렉터리 워크플로/ 파일 build.yml에서 이 작업을 수행합니다. 여기에서 마스터 브랜치를 빌드할 때의 작업을 설명합니다.

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean package -DskipTests

on — 이것은 스크립트가 실행될 이벤트에 대한 설명입니다.

켜기: pull_request/push — 마스터에 대한 푸시가 이루어지고 풀 요청이 생성될 때마다 이 워크플로를 시작해야 함을 나타냅니다.

다음은 작업에 대한 설명입니다(작업) 및 실행 단계(단계) 각 작업마다.

계속해서 - 여기서 대상 OS를 선택할 수 있습니다. 놀랍게도 Mac OS도 선택할 수 있지만 개인 리포지토리에서는 Linux에 비해 상당히 비쌉니다.

사용 예를 들어 actions/setup-java 작업을 사용하여 Java 11용 환경을 설치하는 등 다른 작업을 재사용할 수 있습니다.

...에 의하여 과 액션을 시작하는 데 사용할 매개변수를 지정할 수 있습니다. 기본적으로 이는 액션에 전달될 인수입니다.

남은 것은 Maven에서 프로젝트 빌드를 실행하는 것뿐입니다. run: mvn -B clean package 플래그 -B 메이븐이 갑자기 우리에게 무언가를 묻고 싶어하지 않도록 비대화형 모드가 필요하다고 말합니다.

엄청난! 이제 마스터에 커밋할 때마다 프로젝트 빌드가 시작됩니다.

테스트 실행 자동화

조립은 좋지만 실제로는 프로젝트를 안전하게 조립할 수 있지만 작동이 되지 않습니다. 따라서 다음 단계는 테스트 실행을 자동화하는 것입니다. 또한 PR 검토를 수행할 때 테스트 통과 결과를 보는 것이 매우 편리합니다. 테스트가 통과했으며 병합을 수행하기 전에 브랜치를 실행하는 것을 잊어버린 사람이 없다는 것을 확실히 알 수 있습니다.

풀 요청을 생성하고 마스터에 병합할 때 테스트를 실행하는 동시에 코드 적용 범위에 대한 보고서 생성을 추가할 것입니다.

name: Build

on:
  pull_request:
    branches:
      - '*'
  push:
    branches:
      - 'master'

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Verify
        run: mvn -B clean verify
      - name: Test Coverage
        uses: codecov/codecov-action@v1
        with:
          token: ${{ secrets.CODECOV_TOKEN }}

테스트를 다루기 위해 jacoco 플러그인과 함께 codecov를 사용합니다. codecov에는 자체 작업이 있지만 풀 요청을 처리하려면 토큰이 필요합니다.

${{ secrets.CODECOV_TOKEN }} — 우리는 이 구성을 한 번 이상 보게 될 것입니다. 비밀은 GitHub에 비밀을 저장하는 메커니즘이며, 저장소 코드 베이스에 포함되어서는 안 되는 비밀번호/토큰/호스트/URL 및 기타 데이터를 거기에 쓸 수 있습니다.

GitHub의 리포지토리 설정에서 비밀에 변수를 추가할 수 있습니다.

에서 토큰을 얻을 수 있습니다. codecov.io GitHub를 통해 승인한 후 공개 프로젝트를 추가하려면 다음과 같은 링크를 따라가면 됩니다. GitHub 사용자 이름/[저장소 이름]. 개인 저장소를 추가할 수도 있습니다. 이를 위해서는 Github에서 애플리케이션에 codecov 권한을 부여해야 합니다.

POM 파일에 jacoco 플러그인을 추가합니다.

<plugin>
	<groupId>org.jacoco</groupId>
	<artifactId>jacoco-maven-plugin</artifactId>
	<version>0.8.4</version>
	<executions>
		<execution>
			<goals>
				<goal>prepare-agent</goal>
			</goals>
		</execution>
		<!-- attached to Maven test phase -->
		<execution>
			<id>report</id>
			<phase>test</phase>
			<goals>
				<goal>report</goal>
			</goals>
		</execution>
	</executions>
</plugin>
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.22.2</version>
	<configuration>
		<reportFormat>plain</reportFormat>
		<includes>
			<include>**/*Test*.java</include>
			<include>**/*IT*.java</include>
		</includes>
	</configuration>
</plugin>

이제 codecov 봇은 각 풀 요청을 입력하고 적용 범위 변경 그래프를 추가합니다.

정적 분석기를 추가해 보겠습니다.

대부분의 오픈 소스 프로젝트에서 정적 코드 분석을 위해 Sonar Cloud를 사용하는데, travis-ci에 연결하는 것은 매우 쉽습니다. 따라서 GitHub Actions로 마이그레이션하여 동일한 작업을 수행하는 것은 논리적인 단계입니다. 액션 시장은 멋진 것이지만 이번에는 조금 실망했습니다. 습관적으로 필요한 액션을 찾아서 워크플로에 추가했기 때문입니다. 그러나 Sonar는 Maven 또는 Gradle에서 프로젝트를 분석하기 위한 작업을 지원하지 않는 것으로 나타났습니다. 물론 문서에 이런 내용이 적혀 있는데 누가 읽나요?!

작업을 통해서는 불가능하므로 mvn 플러그인을 통해 수행하겠습니다.

name: SonarCloud

on:
  push:
    branches:
      - master
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  sonarcloud:
    runs-on: ubuntu-16.04
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Analyze with SonarCloud
#       set environment variables:
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
#       run sonar maven plugin:
        run: mvn -B verify sonar:sonar -Dsonar.projectKey=antkorwin_github-actions -Dsonar.organization=antkorwin-github -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=$SONAR_TOKEN -Dsonar.coverage.jacoco.xmlReportPaths=./target/site/jacoco/jacoco.xml

SONAR_TOKEN - 다음에서 구할 수 있습니다. sonarcloud.io 비밀글로 등록해야 합니다. GITHUB_TOKEN - 이는 GitHub가 생성하는 내장 토큰으로, 이를 통해 sonarcloud[bot]가 Git에 로그인하여 풀 요청에 메시지를 남길 수 있습니다.

Dsonar.projectKey — 소나의 프로젝트 이름은 프로젝트 설정에서 확인할 수 있습니다.

Dsonar.조직 — GitHub의 조직 이름입니다.

풀 요청을 하고 sonarcloud[bot]가 댓글에 올 때까지 기다립니다.

릴리스 관리

빌드가 구성되었고 테스트가 실행되었으므로 릴리스를 만들 수 있습니다. GitHub Actions를 통해 릴리스 관리가 어떻게 훨씬 쉬워지는지 살펴보겠습니다.

직장에는 코드 베이스가 bitbucket에 있는 프로젝트가 있습니다(모든 것이 "낮에는 bitbucket에 쓰고 밤에는 GitHub에 커밋합니다"라는 이야기와 같습니다). 불행하게도 bitbucket에는 릴리스 관리 도구가 내장되어 있지 않습니다. 각 릴리스에 대해 수동으로 합류 페이지를 생성하고 릴리스에 포함된 모든 기능을 거기에 던져야 하고, 마음의 궁전을 검색하고, Jira의 작업을 검색하고, 저장소에서 커밋해야 하기 때문에 이것이 문제입니다. 실수할 가능성이 많으며, 무언가를 잊거나 지난번에 이미 릴리스된 것을 입력할 수 있습니다. 때로는 끌어오기 요청을 무엇으로 분류해야 할지 명확하지 않습니다. 기능인지, 버그 수정인지, 테스트 편집인지, 아니면 뭔가 인프라적인 것 .

GitHub 작업이 어떻게 우리에게 도움이 될 수 있나요? 훌륭한 작업이 있습니다. 릴리스 초안을 사용하면 릴리스 노트 파일 템플릿을 설정하여 풀 요청 카테고리를 설정하고 릴리스 노트 파일에서 자동으로 그룹화할 수 있습니다.

보고서 설정을 위한 예제 템플릿(.github/release-drafter.yml):

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: ' New Features'
    labels:
      - 'type:features'
# в эту категорию собираем все PR с меткой type:features

  - title: ' Bugs Fixes'
    labels:
      - 'type:fix'
# аналогично для метки type:fix и т.д.

  - title: ' Documentation'
    labels:
      - 'type:documentation'

  - title: ' Configuration'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Changes
  $CHANGES

초안 릴리스를 생성하는 스크립트를 추가합니다(.github/workflows/release-draft.yml).

name: "Create draft release"

on:
  push:
    branches:
      - master

jobs:
  update_draft_release:
    runs-on: ubuntu-18.04
    steps:
      - uses: release-drafter/release-drafter@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

이제부터 모든 풀 요청은 릴리스 노트에 자동으로 수집됩니다. 마법입니다!

여기서 질문이 생길 수 있습니다. 개발자가 PR에 태그를 넣는 것을 잊어버리면 어떻게 될까요? 그러면 어떤 카테고리에 넣어야 할지 명확하지 않으며 다시 각 PR을 개별적으로 수동으로 처리해야 합니다. 이 문제를 해결하려면 다른 작업(레이블 검증기)을 사용하여 풀 요청에 태그가 있는지 확인하면 됩니다. 필수 태그가 없으면 확인이 실패하고 풀 요청에 이에 대한 메시지가 표시됩니다.

name: "Verify type labels"

on:
  pull_request:
    types: [opened, labeled, unlabeled, synchronize]

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: zwaldowski/match-label-action@v2
        with:
          allowed: 'type:fix, type:features, type:documentation, type:tests, type:config'

이제 모든 풀 요청은 type:fix, type:features, type:documentation, type:tests, type:config 태그 중 하나로 표시되어야 합니다.

풀 요청의 자동 주석

끌어오기 요청을 통한 효과적인 작업과 같은 주제를 다루었으므로 라벨러와 같은 작업에 대해 이야기할 가치가 있습니다. 이는 변경된 파일을 기반으로 PR에 태그를 추가합니다. 예를 들어 디렉터리에 대한 변경 사항이 포함된 풀 요청을 [build]로 표시할 수 있습니다. .github/workflow.

연결하는 것은 매우 간단합니다.

name: "Auto-assign themes to PR"

on:
  - pull_request

jobs:
  triage:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/labeler@v2
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

또한 프로젝트 디렉터리와 끌어오기 요청 주제 간의 대응 관계를 설명하는 파일이 필요합니다.

theme:build:
  - ".github/**"
  - "pom.xml"
  - ".travis.yml"
  - ".gitignore"
  - "Dockerfile"

theme:code:
  - "src/main/*"

theme:tests:
  - "src/test/*"

theme:documentation:
  - "docs/**"

theme:TRASH:
  - ".idea/**"
  - "target/**"

풀 요청에 자동으로 레이블을 배치하는 작업과 필수 레이블이 있는지 확인하는 작업을 연결하는 데 성공하지 못했습니다. match-label은 봇이 추가한 레이블을 보고 싶어하지 않습니다. 두 단계를 결합한 자신만의 액션을 작성하는 것이 더 쉬운 것 같습니다. 하지만 이 형식에서도 사용하기가 매우 편리합니다. 끌어오기 요청을 생성할 때 목록에서 레이블을 선택해야 합니다.

배포할 시간입니다.

GitHub Actions(ssh를 통해, scp를 통해, docker-hub를 사용하여)를 통해 여러 배포 옵션을 시도했는데, 아마도 파이프라인이 아무리 비뚤어져 있더라도 바이너리를 서버에 업로드하는 방법을 찾을 수 있을 것이라고 말할 수 있습니다. 이다.

전체 인프라를 한 곳에 보관할 수 있는 옵션이 마음에 들었으므로 GitHub 패키지(바이너리 콘텐츠, npm, jar, docker용 저장소)에 배포하는 방법을 살펴보겠습니다.

Docker 이미지를 빌드하고 GitHub 패키지에 게시하기 위한 스크립트:

name: Deploy docker image

on:
  push:
    branches:
      - 'master'

jobs:

  build_docker_image:
    runs-on: ubuntu-18.04
    steps:

#     Build JAR:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean compile package -DskipTests

#     Set global environment variables:
      - name: set global env
        id: global_env
        run: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Build Docker image:
      - name: Build and tag image
        run: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - name: Docker login
        run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publish image to github package repository:
      - name: Publish image
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

먼저 애플리케이션의 JAR 파일을 빌드한 후 GitHub 도커 레지스트리 경로와 이미지 이름을 계산해야 합니다. 여기에는 아직 발견하지 못한 몇 가지 트릭이 있습니다.

• echo "::set-output name=NAME::VALUE"와 같은 구성을 사용하면 현재 단계에서 변수 값을 설정하여 다른 모든 단계에서 읽을 수 있습니다.
• 이 단계의 식별자 ${{ steps.global_env.outputs.DOCKEHUB_IMAGE_NAME }} 를 통해 이전 단계에서 설정된 변수의 값을 얻을 수 있습니다.
• 표준 GITHUB_REPOSITORY 변수는 저장소 이름과 소유자(“owner/repo-name”)를 저장합니다. 저장소 이름을 제외하고 이 줄에서 모든 내용을 잘라내기 위해 bash 구문을 사용합니다: ${GITHUB_REPOSITORY#*/}

다음으로 Docker 이미지를 빌드해야 합니다.

docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"

레지스트리에 로그인합니다:

docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

그리고 이미지를 GitHub 패키지 저장소에 게시합니다.

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

이미지 버전을 표시하기 위해 커밋 SHA 해시의 첫 번째 숫자를 사용합니다. GITHUB_SHA 마스터에 병합할 때뿐만 아니라 풀 요청 생성에 따라 이러한 빌드를 만드는 경우 여기에도 뉘앙스가 있습니다. 이벤트가 발생하면 SHA는 git 기록에 표시된 해시와 일치하지 않을 수 있습니다. 작업/체크아웃 작업이 PR의 교착 상태 작업을 피하기 위해 고유한 해시를 만들기 때문입니다.

모든 것이 잘 작동했다면 저장소에서 패키지 섹션(https://github.com/antkorwin/github-actions/packages)을 열면 새로운 도커 이미지가 표시됩니다.

여기에서 Docker 이미지 버전 목록도 볼 수 있습니다.

남은 것은 이 레지스트리와 작동하도록 서버를 구성하고 서비스를 다시 시작하는 것입니다. 나중에 systemd를 통해 이 작업을 수행하는 방법에 대해 이야기하겠습니다.

모니터링

GitHub Actions를 사용하여 애플리케이션의 상태 확인을 수행하는 방법에 대한 간단한 옵션을 살펴보겠습니다. 우리의 부팅 애플리케이션에는 액추에이터가 있으므로 상태를 확인하기 위해 API를 작성할 필요조차 없습니다. 게으른 사용자를 위해 이미 모든 작업을 완료했습니다. 호스트를 끌어오기만 하면 됩니다. SERVER-URL:PORT/actuator/health

$ curl -v 127.0.0.1:8080/actuator/health

> GET /actuator/health HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.61.1
> Accept: */*

< HTTP/1.1 200
< Content-Type: application/vnd.spring-boot.actuator.v3+json
< Transfer-Encoding: chunked
< Date: Thu, 04 Jun 2020 12:33:37 GMT

{"status":"UP"}

우리에게 필요한 것은 cron을 사용하여 서버를 확인하는 작업을 작성하는 것뿐입니다. 갑자기 서버가 응답하지 않으면 텔레그램으로 알림을 보냅니다.

먼저 cron 작업 흐름을 실행하는 방법을 알아 보겠습니다.

on:
  schedule:
    - cron:  '*/5 * * * *'

간단합니다. Github에서 웹훅에 전혀 맞지 않는 이벤트를 만들 수 있다는 사실조차 믿을 수 없습니다. 자세한 내용은 문서에 나와 있습니다. help.github.com/en/actions/reference/events-that-trigger-workflows#scheduled-events-schedule

컬을 통해 수동으로 서버 상태를 확인해 보겠습니다.

jobs:
  ping:
    runs-on: ubuntu-18.04
    steps:

      - name: curl actuator
        id: ping
        run: |
          echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"

      - name: health check
        run: |
          if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
            echo "health check is failed"
            exit 1
          fi
          echo "It's OK"

먼저, 서버가 요청에 응답한 내용을 변수에 저장하고, 다음 단계에서는 상태가 UP인지 확인하고, 그렇지 않은 경우 오류와 함께 종료합니다. 손으로 어떤 행동을 "압도"해야 한다면, 1 번 출구 - 적합한 무기.

  - name: send alert in telegram
    if: ${{ failure() }}
    uses: appleboy/telegram-action@master
    with:
      to: ${{ secrets.TELEGRAM_TO }}
      token: ${{ secrets.TELEGRAM_TOKEN }}
      message: |
        Health check of the:
        ${{secrets.SERVER_HOST}}/api/actuator/health
        failed with the result:
        ${{ steps.ping.outputs.status }}

이전 단계에서 작업이 실패한 경우에만 텔레그램으로 보냅니다. 메시지를 보내려면 appleboy/telegram-action을 사용합니다. 문서에서 봇 토큰과 채팅 ID를 얻는 방법을 읽을 수 있습니다. github.com/appleboy/telegram-action

Github에 서버의 URL과 텔레그램 봇의 토큰에 대한 비밀을 작성하는 것을 잊지 마십시오.

보너스 트랙 - 게으른 사람들을 위한 JIRA

저는 JIRA로 돌아가겠다고 약속했고, 돌아왔습니다. 나는 개발자가 기능을 만들고 브랜치를 병합했지만 문제를 JIRA로 끌어오는 것을 잊어버린 스탠드업 상황을 수백 번 관찰했습니다. 물론 이 모든 작업을 한 곳에서 수행하면 더 쉬울 수 있지만 실제로는 IDE에서 코드를 작성하고 브랜치를 bitbucket 또는 GitHub에 병합한 다음 작업을 Jira로 드래그합니다. 이를 위해서는 새 창을 열어야 합니다. , 때로는 다시 로그인하는 등의 작업이 있습니다. 다음에 해야 할 일을 완벽하게 기억하면 보드를 다시 열 필요가 없습니다. 결과적으로 아침에 스탠드업에서 작업 보드를 업데이트하는 데 시간을 보내야 합니다.

GitHub는 이 일상적인 작업에도 도움이 됩니다. 우선 풀 요청을 제출할 때 이슈를 code_review 열에 자동으로 끌어 놓을 수 있습니다. 당신이 해야 할 일은 브랜치 명명 규칙을 따르는 것 뿐입니다:

[имя проекта]-[номер таска]-название

예를 들어 프로젝트 키 "GitHub Actions"가 GA인 경우 GA-8-jira-bot GA-8 작업을 구현하기 위한 분기가 될 수 있습니다.

JIRA와의 통합은 Atlassian의 작업을 통해 이루어지지만 완벽하지는 않습니다. 일부는 저에게 전혀 효과가 없었습니다. 그러나 우리는 확실히 작동하고 적극적으로 사용되는 것들에 대해서만 논의할 것입니다.

먼저 atlassian/gajira-login 작업을 사용하여 JIRA에 로그인해야 합니다.

jobs:
  build:
    runs-on: ubuntu-latest
    name: Jira Workflow
    steps:
      - name: Login
        uses: atlassian/gajira-login@master
        env:
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

이렇게 하려면 JIRA에서 토큰을 가져와야 합니다. 이를 수행하는 방법은 여기에 설명되어 있습니다. confluence.atlassian.com/cloud/api-tokens-938839638.html

브랜치 이름에서 작업 식별자를 추출합니다.

  - name: Find Issue
    id: find_issue
    shell: bash
    run: |
      echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
      echo brach name: $GITHUB_HEAD_REF
      echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'

  - name: Check Issue
    shell: bash
    run: |
      if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
        echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}

GitHub 마켓플레이스에서 검색하면 이 작업에 대한 작업을 찾을 수 있지만 Atlassian의 이 작업은 어떤 식으로든 내 프로젝트에서 작업하고 싶지 않았기 때문에 브랜치 이름을 사용하여 grep을 사용하여 동일한 작업을 작성해야 했습니다. , 거기에 무엇이 잘못되었는지 알아내려면 손으로 같은 일을 하는 것보다 더 오래 걸립니다.

남은 것은 끌어오기 요청을 생성할 때 작업을 "코드 검토" 열로 이동하는 것입니다.

  - name: Transition issue
    if: ${{ success() }}
    uses: atlassian/gajira-transition@master
    with:
      issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
      transition: "Code review"

GitHub에는 이에 대한 특별한 조치가 있습니다. 필요한 것은 이전 단계에서 얻은 이슈 ID와 위에서 수행한 JIRA의 승인뿐입니다.

같은 방식으로 마스터에 병합할 때 작업과 GitHub 워크플로의 다른 이벤트를 끌어서 놓을 수 있습니다. 일반적으로 모든 것은 일상적인 프로세스를 자동화하려는 상상력과 욕구에 달려 있습니다.

조사 결과

클래식 DEVOPS 다이어그램을 보면 운영을 제외한 모든 단계를 다루었습니다. 시도해 보면 시장에서 헬프 데스크 시스템과의 통합을 위한 몇 가지 조치를 찾을 수 있으므로 파이프라인이 전환되었다고 가정합니다. 철저하게 분석하고 그 사용에 따라 결론을 도출할 수 있습니다.

장점 :

• 모든 경우에 대해 미리 준비된 작업을 제공하는 마켓플레이스는 매우 멋지습니다. 대부분의 경우 소스 코드를 보고 유사한 문제를 해결하는 방법을 이해하거나 GitHub 저장소에 직접 작성자에게 기능 요청을 게시할 수도 있습니다.
• 어셈블리 대상 플랫폼 선택: Linux, mac os, windows는 매우 흥미로운 기능입니다.
• Github 패키지는 훌륭한 기능입니다. 전체 인프라를 한 곳에 보관하는 것이 편리하고, 다른 창을 통해 서핑할 필요가 없으며, 모든 것이 한두 번의 마우스 클릭 반경 내에 있으며 GitHub Actions와 완벽하게 통합됩니다. 무료 버전의 Docker 레지스트리 지원도 좋은 장점입니다.
• GitHub는 빌드 로그에 비밀을 숨기므로 이를 사용하여 비밀번호와 토큰을 저장하는 것은 그다지 무섭지 않습니다. 모든 실험 동안 콘솔에서 순수한 형태의 비밀을 볼 수 없었습니다.
• 오픈 소스 프로젝트의 경우 무료

단점 :

• YML, 음, 난 그 사람을 좋아하지 않아요. 이러한 흐름으로 작업할 때 제가 받은 가장 일반적인 커밋 메시지는 "yml 형식 수정"입니다. 그런 다음 탭을 어딘가에 두는 것을 잊어버렸거나 잘못된 줄에 썼습니다. 일반적으로 각도기와 자를 들고 스크린 앞에 앉아 있는 것은 가장 즐거운 경험이 아닙니다.
• DEBUG, 커밋으로 흐름 디버깅, 재구축 실행 및 콘솔로 출력하는 것이 항상 편리한 것은 아니지만 "과도한 작업" 범주에 가깝습니다. 무엇이든 디버깅할 수 있으면 편리한 IDEA를 사용하여 작업하는 데 익숙합니다. .
• Docker로 래핑하면 무엇이든 액션을 작성할 수 있지만 기본적으로 javascript만 지원됩니다. 물론 이것은 취향의 문제이지만 js 대신 다른 것을 선호합니다.

모든 스크립트가 포함된 저장소는 다음과 같습니다. github.com/antkorwin/github-actions

다음주에는 같이 공연할 거예요 보고서 Heisenbug 2020 Piter 컨퍼런스에서. 테스트 데이터를 준비할 때 실수를 피하는 방법뿐만 아니라 Java 애플리케이션에서 데이터 세트로 작업하는 비결도 알려드리겠습니다!

출처 : habr.com