GitHub әрекеттері бар тозақ шеңберлері (Java жобасы үшін CI/CD құбырын құру)

Мен Java-да жобаларды құру үшін жиі құбыр салуға тура келеді. Кейде бұл ашық бастапқы код, кейде олай емес. Жақында мен өзімнің кейбір репозиторийлерімді Travis-CI және TeamCity-тен GitHub әрекеттеріне көшіріп көруді шештім, бұл одан шықты.

Біз нені автоматтандырамыз?

Біріншіден, бізге автоматтандыратын жоба керек, Spring boot / Java 11 / Maven ішінде шағын қосымшаны жасайық. Осы мақаланың мақсаттары үшін қолданба логикасы бізді мүлдем қызықтырмайды; біз үшін қосымшаның айналасындағы инфрақұрылым маңызды, сондықтан бізге қарапайым REST API контроллері жеткілікті.

Дереккөздерді мына жерден көре аласыз: github.com/antkorwin/github-actions Құбырды салудың барлық кезеңдері осы жобаның тарту сұрауларында көрсетілген.

JIRA және жоспарлау

Айта кету керек, біз әдетте JIRA-ны мәселені бақылаушы ретінде қолданамыз, сондықтан осы жоба үшін бөлек тақта жасап, бірінші мәселелерді сол жерге қосамыз:

Біраз уақыттан кейін біз JIRA мен GitHub ұсына алатын қызықты нәрселерге ораламыз.

Біз жобаны құрастыруды автоматтандырамыз

Біздің сынақ жобамыз maven арқылы жасалған, сондықтан оны құру өте қарапайым, бізге тек mvn таза пакеті қажет.

Мұны Github Actions көмегімен орындау үшін бізге жұмыс үрдісін сипаттайтын репозиторийде файл жасау керек болады, мұны кәдімгі yml файлымен жасауға болады, мен «yml бағдарламалауды» ұнатамын деп айта алмаймын, бірақ біз не істей аламыз - біз мұны .github/ directory workflow/ 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_quest/push — бұл жұмыс үрдісін шеберге итеру және тарту сұраулары жасалған сайын іске қосу қажет екенін көрсетеді.

Төменде тапсырмалардың сипаттамасы берілген (жұмыс орны) және орындау қадамдары (қадамдар) әрбір тапсырма үшін.

жүгіру - мұнда біз мақсатты ОЖ таңдай аламыз, таңқаларлық, сіз тіпті 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 қолданбасында кодов құқықтарын беру керек.

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 бұлтын қолданамын, travis-ci-ге қосылу өте оңай. Сондықтан бұл GitHub әрекеттеріне көшу кезінде дәл солай істеу үшін қисынды қадам. Экшн нарығы керемет нәрсе, бірақ бұл жолы ол мені аздап ренжітті, өйткені әдеттен тыс мен қажетті әрекетті тауып, оны жұмыс процесіне қостым. Бірақ 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.organization — GitHub сайтынан ұйымның атауы.

Біз тарту сұрауын жасаймыз және sonarcloud[bot] түсініктемелерде келуін күтеміз:

Шығарылымды басқару

Құрастыру конфигурацияланды, сынақтар орындалды және біз шығарылым жасай аламыз. GitHub әрекеттері шығарылымды басқаруды қалай жеңілдететінін қарастырайық.

Жұмыста менің кодтық базасы битбукетте болатын жобаларым бар (бәрі сол әңгімедегідей «Мен күндіз битбукетке жазамын, түнде GitHub-қа жазыламын»). Өкінішке орай, bitbucket-те кірістірілген шығарылымды басқару құралдары жоқ. Бұл мәселе, өйткені әрбір шығарылым үшін қолмен бетті біріктіру керек және шығарылымға енгізілген барлық мүмкіндіктерді сол жерге тастау керек, ақыл-ой сарайларын, джирадағы тапсырмаларды, репозиторийдегі тапсырмаларды іздеу керек. Қателік жасау мүмкіндігі көп, сіз бір нәрсені ұмыта аласыз немесе соңғы рет шығарылған нәрсені енгізе аласыз, кейде тарту сұрауын не ретінде жіктеу түсініксіз болады - бұл мүмкіндік пе, қатені түзету немесе өңдеу сынақтары ма, әлде инфрақұрылымдық нәрсе.

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-ға тегтерді қояды. Мысалы, біз каталогқа өзгертулерді қамтитын кез келген тарту сұрауын [құрастыру] ретінде белгілей аламыз .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/**"

Мен тарту сұрауларында белгілерді автоматты түрде орналастыратын әрекетті қажетті белгілердің бар-жоғын тексеретін әрекетпен жұптастыру сәтсіз болды; сәйкестік белгісі бот қосқан белгілерді көргісі келмейді. Екі кезеңді біріктіретін өз әрекетіңізді жазу оңайырақ сияқты. Бірақ бұл пішінде де оны пайдалану өте ыңғайлы, тарту сұрауын жасау кезінде тізімнен белгіні таңдау керек.

Орналастыру уақыты келді

Мен GitHub әрекеттері арқылы (ssh арқылы, scp арқылы және docker-hub арқылы) бірнеше орналастыру опцияларын қолданып көрдім және мен айта аламын, сіз құбырыңыз қаншалықты қисық болса да, екілік файлды серверге жүктеп салудың жолын таба аласыз. болып табылады.

Маған бүкіл инфрақұрылымды бір жерде сақтау опциясы ұнады, сондықтан GitHub пакеттеріне қалай орналастыру керектігін қарастырайық (бұл екілік мазмұнға арналған репозиторий, npm, jar, докер).

Докер кескінін құруға және оны 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.DOCKERHUB_IMAGE_NAME }}
• Стандартты GITHUB_REPOSITORY айнымалысы репозиторий мен оның иесінің атын сақтайды («иесі/репо-аты»). Осы жолдан репозиторий атауынан басқаның барлығын қиып алу үшін біз bash синтаксисін қолданамыз: ${GITHUB_REPOSITORY#*/}

Әрі қарай докер кескінін құру керек:

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 біз гит тарихында көретін хэшке сәйкес келмеуі мүмкін, себебі әрекеттер/тексеру әрекеті PR-дағы тығырықтан шығу әрекеттерін болдырмау үшін өзінің бірегей хэшін жасайды.

Егер бәрі ойдағыдай болса, репозиторийдегі бумалар бөлімін (https://github.com/antkorwin/github-actions/packages) ашсаңыз, сіз жаңа докер кескінін көресіз:

Мұнда сіз докер кескінінің нұсқаларының тізімін де көре аласыз.

Бұл тізіліммен жұмыс істеу үшін серверді конфигурациялау және қызметті қайта іске қосу ғана қалады. Мен мұны systemd арқылы қалай жасау керектігі туралы басқа уақытта айтатын шығармын.

Бақылау

GitHub әрекеттері арқылы қолданбамыздың денсаулығын тексеру әдісінің қарапайым опциясын қарастырайық. Біздің жүктеу қосымшамызда жетек бар, сондықтан оның күйін тексеру үшін 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

Сервер күйін curl арқылы қолмен тексерейік:

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"

Біріншіден, сервер сұрауға не жауап бергенін айнымалыға сақтаймыз, келесі қадамда күйдің ЖОҒАРЫ екенін тексереміз және егер олай болмаса, қатемен шығамыз. Егер сізге әрекетті қолыңызбен «басып тастау» керек болса, онда 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 }}

Алдыңғы қадамда әрекет сәтсіз болған жағдайда ғана Telegram-ға жібереміз. Хабарламаны жіберу үшін біз appleboy/telegram-action пайдаланамыз; сіз құжаттамада бот белгісін және чат идентификаторын қалай алуға болатынын оқи аласыз: 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 әрекеттері арқылы жұмыс істейді, олар мінсіз емес, олардың кейбіреулері мен үшін мүлдем жұмыс істемеді деп айтуым керек. Бірақ біз міндетті түрде жұмыс істейтін және белсенді қолданылатындарды ғана талқылаймыз.

Алдымен JIRA жүйесіне әрекетті пайдаланып кіру керек: atlassian/gajira-login

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 нарығында іздесеңіз, сіз осы тапсырма үшін әрекетті таба аласыз, бірақ мен grep арқылы филиалдың атын пайдаланып бірдей нәрсені жазуға тура келді, өйткені Atlassian-ның бұл әрекеті менің жобамда ешқандай түрде жұмыс істегісі келмеді. , онда не дұрыс емес екенін анықтау үшін - қолыңызбен бірдей нәрсені жасаудан ұзағырақ.

Тек тарту сұрауын жасау кезінде тапсырманы «Кодты қарау» бағанына жылжыту ғана қалады:

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

Бұл үшін GitHub-та арнайы әрекет бар, оған тек алдыңғы қадамда алынған мәселе идентификаторы және жоғарыда біз жасаған JIRA авторизациясы қажет.

Сол сияқты, GitHub жұмыс процесінен негізгі және басқа оқиғаларды біріктіру кезінде тапсырмаларды сүйреуге болады. Жалпы, бәрі сіздің қиялыңызға және күнделікті процестерді автоматтандыруға деген ниетіңізге байланысты.

қорытындылар

Егер сіз классикалық DEVOPS диаграммасына қарасаңыз, біз барлық кезеңдерді қамтыдық, мүмкін операциядан басқа, менің ойымша, егер сіз тырыссаңыз, нарықта анықтамалық жүйемен интеграциялау үшін қандай да бір әрекетті таба аласыз, сондықтан құбыр бұрылды деп есептейміз. тиянақты болуы керек және оны пайдалану негізінде қорытынды жасауға болады.

Артықшылықтары:

• Барлық жағдайларға арналған дайын әрекеттері бар базар, бұл өте керемет. Олардың көпшілігінде ұқсас мәселені шешу жолын түсіну үшін бастапқы кодты қарауға немесе авторға тікелей GitHub репозиторийінде мүмкіндік сұрауын жіберуге болады.
• Құрастыру үшін мақсатты платформаны таңдау: Linux, mac os, windows - бұл өте қызықты мүмкіндік.
• Github пакеттері - бұл тамаша нәрсе, бүкіл инфрақұрылымды бір жерде ұстау ыңғайлы, әртүрлі терезелер арқылы шарлаудың қажеті жоқ, барлығы бір немесе екі тінтуірді басу радиусында және GitHub әрекеттерімен тамаша біріктірілген. Тегін нұсқада Docker тізілімін қолдау да жақсы артықшылық болып табылады.
• GitHub құрастыру журналдарында құпияларды жасырады, сондықтан оны құпия сөздер мен таңбалауыштарды сақтау үшін пайдалану соншалықты қорқынышты емес. Барлық эксперименттерімде мен консольдегі құпияны оның таза түрінде ешқашан көре алмадым.
• Ашық бастапқы жобалар үшін тегін

Кемшіліктері:

• YML, мен оны ұнатпаймын. Мұндай ағынмен жұмыс істегенде, менде ең көп тараған міндеттеме хабары «yml пішімін түзету» болып табылады, кейде сіз бір жерге қойынды қоюды ұмытып кетесіз, кейде оны дұрыс емес жолға жазасыз. Жалпы, транспортир мен сызғышы бар экранның алдында отыру ең жағымды тәжірибе емес.
• DEBUG, тапсырмалар арқылы ағынды жөндеу, қайта құруды іске қосу және консольге шығару әрқашан қолайлы бола бермейді, бірақ бұл «сіз асып кеттіңіз» санатына жатады; сіз кез келген нәрсені жөндеуге болатын ыңғайлы IDEA-мен жұмыс істеуге дағдыланғансыз. .
• Егер сіз оны Docker-ге орап алсаңыз, кез келген нәрсеге өз әрекетіңізді жаза аласыз, бірақ тек JavaScript-ке жергілікті түрде қолдау көрсетіледі, әрине, бұл талғам мәселесі, бірақ мен JS орнына басқа нәрсені қалаймын.

Еске сала кетейін, барлық сценарийлері бар репозиторий осында: github.com/antkorwin/github-actions

Келесі аптада мен бірге өнер көрсетемін есеп беру Heisenbug 2020 Питер конференциясында. Мен сізге сынақ деректерін дайындау кезінде қателерді қалай болдырмау керектігін айтып қана қоймай, сонымен қатар Java қолданбаларында деректер жиынымен жұмыс істеу құпияларымен бөлісемін!

Ақпарат көзі: www.habr.com