د GitHub اعمالو سره د دوزخ حلقې (د جاوا پروژې لپاره د CI/CD پایپ لاین جوړول)

زه ډیری وختونه باید په جاوا کې د پروژو جوړولو لپاره پایپ لاین جوړ کړم. ځینې ​​​​وختونه دا خلاص سرچینه ده، ځینې وختونه دا ندي. ما پدې وروستیو کې پریکړه وکړه چې زما ځینې زیرمې د Travis-CI او TeamCity څخه GitHub اعمالو ته لیږدولو هڅه وکړم ، او دا هغه څه دي چې له دې څخه راپورته شوي.

موږ به څه اتومات کړو؟

لومړی، موږ یوې پروژې ته اړتیا لرو چې موږ به اتومات کړو، راځئ چې په پسرلي بوټ / جاوا 11 / ماون کې یو کوچنی غوښتنلیک جوړ کړو. د دې مقالې اهدافو لپاره ، موږ به په هیڅ ډول د غوښتنلیک منطق سره علاقه نلرو؛ د غوښتنلیک شاوخوا زیربنا زموږ لپاره مهمه ده ، نو یو ساده REST API کنټرولر به زموږ لپاره کافي وي.

تاسو کولی شئ دلته سرچینې وګورئ: github.com/antkorwin/github-actions د پایپ لاین د جوړولو ټولې مرحلې د دې پروژې لپاره د پلولو غوښتنو کې منعکس شوي.

JIRA او پلان جوړونه

دا د ویلو وړ ده چې موږ معمولا JIRA د مسلې تعقیبونکي په توګه کاروو ، نو راځئ چې د دې پروژې لپاره جلا بورډ جوړ کړو او لومړۍ مسلې پکې اضافه کړو:

یو څه وروسته به موږ بیرته هغه په ​​زړه پورې شیان ته ورشو چې JIRA او GitHub کولی شي په ترکیب کې وړاندیز وکړي.

موږ د پروژې مجلس اتومات کوو

زموږ د ازموینې پروژه د ماون له لارې جوړه شوې ، نو د دې جوړول خورا ساده دي ، ټول هغه څه چې موږ ورته اړتیا لرو د mvn پاک کڅوړه ده.

د ګیتوب عملونو په کارولو سره د دې کولو لپاره ، موږ اړتیا لرو په ذخیره کې یو فایل رامینځته کړو چې زموږ د کاري فلو تشریح کوي ، دا د منظم yml فایل سره ترسره کیدی شي ، زه نشم ویلای چې زه د "yml برنامه" خوښوم ، مګر موږ څه کولی شو - موږ دا په .github/ Directory workflow/ file 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 غوره کړو ، په حیرانتیا سره ، تاسو حتی کولی شئ ماک OS غوره کړئ ، مګر په شخصي ذخیره کې دا خورا ګران دی (د لینکس په پرتله).

هغه ګټي تاسو ته اجازه درکوي چې نورې کړنې بیا وکاروئ، د بیلګې په توګه، د عمل/setup-java عمل په کارولو سره موږ د جاوا 11 لپاره چاپیریال نصب کوو.

د مرستې په مرسته سره موږ کولی شو هغه پیرامیټونه مشخص کړو چې موږ یې عمل پیل کوو، په اصل کې دا هغه دلیلونه دي چې عمل ته به لیږدول کیږي.

ټول هغه څه چې په ماوین کې د پروژې جوړونې پرمخ وړل دي: 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 }}

د ازموینې پوښلو لپاره، زه کوډکوف د جاکوکو پلگ ان سره په ګډه کاروم. کوډکوف خپل عمل لري، مګر دا زموږ د پلې غوښتنې سره کار کولو لپاره نښه ته اړتیا لري:

${{ secrets.CODECOV_TOKEN }} - موږ به دا جوړښت له یو ځل څخه ډیر وګورو، رازونه په GitHub کې د رازونو ذخیره کولو میکانیزم دی، موږ کولی شو هلته پاسورډونه/ټوکنز/میزبان/urls او نور معلومات ولیکو چې باید د ذخیره کوډ بیس کې شامل نه وي.

تاسو کولی شئ په GitHub کې د ذخیره کولو تنظیماتو کې رازونو ته متغیر اضافه کړئ:

تاسو کولی شئ په نښه کړئ codecov.io د GitHub له لارې د واک ورکولو وروسته ، د عامه پروژې اضافه کولو لپاره تاسو اړتیا لرئ د دې په څیر لینک تعقیب کړئ: د GitHub کارن نوم/[ریپو نوم]. یو شخصي ذخیره هم اضافه کیدی شي؛ د دې کولو لپاره ، تاسو اړتیا لرئ په ګیتوب کې غوښتنلیک ته د کوډکوف حق ورکړئ.

د POM فایل ته د جاکوکو پلگ ان اضافه کړئ:

<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>

اوس د کوډکوف بوټ به زموږ هرې پلې غوښتنې ته ننوځي او د پوښښ بدلون ګراف به اضافه کړي:

راځئ چې یو جامد شنونکی اضافه کړو

زما د خلاصې سرچینې په ډیری پروژو کې زه د جامد کوډ تحلیل لپاره سونار کلاوډ کاروم ، دا د travis-ci سره وصل کول خورا اسانه دي. نو دا یو منطقي ګام دی کله چې د ورته کولو لپاره د GitHub اعمالو ته مهاجرت وکړئ. د عمل بازار یو ښه شی دی، مګر دا ځل یې ما یو څه ټیټ کړ، ځکه چې د عادت له مخې ما هغه عمل وموند چې ما ورته اړتیا درلوده او د کار فلو کې یې اضافه کړه. مګر دا معلومه شوه چې سونار د میون یا ګریډل پروژو تحلیل لپاره د عمل له لارې کار کولو ملاتړ نه کوي. البته، دا په اسنادو کې لیکل شوي، مګر څوک یې لوستل؟!

دا د عمل له لارې امکان نلري ، نو موږ به یې د 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 رامینځته کوي ، د کوم په مرسته چې سونار کلاډ [بوټ] به وکولی شي ګیټ ته لاګ ان شي ترڅو موږ ته د پل په غوښتنو کې پیغامونه پریږدي.

dsonar.projectKey - په سونار کې د پروژې نوم، تاسو کولی شئ دا د پروژې ترتیباتو کې وګورئ.

dsonar.organization - د GitHub څخه د سازمان نوم.

موږ د پلټ غوښتنه کوو او د سونار کلاډ [بوټ] ته په نظرونو کې د راتلو انتظار کوو:

د خپرولو مدیریت

جوړښت ترتیب شوی، ازموینې پرمخ وړل شوي، او موږ کولی شو خوشې کړو. راځئ وګورو چې څنګه د GitHub کړنې کولی شي د خوشې کولو مدیریت خورا اسانه کړي.

په کار کې ، زه پروژې لرم چې د کوډ اساس یې په بټ بکټ کې دی (هر څه د دې کیسه په څیر دي "زه د ورځې په جریان کې بټ بکټ ته لیکم ، د شپې ګیټ هب ته ژمن یم"). له بده مرغه، بټ بکټ د خوشې کولو مدیریت وسیلې نلري. دا یوه ستونزه ده ، ځکه چې د هرې خوشې کیدو لپاره تاسو باید په لاسي ډول په ترکیب کې یوه پاڼه جوړه کړئ او په ریلیز کې شامل ټولې ځانګړتیاوې هلته وغورځوئ ، د ذهن په محلونو کې لټون وکړئ ، په جیرا کې دندې ، په ذخیره کې ژمنې وکړئ. د خطا کولو ډیری چانسونه شتون لري، تاسو کولی شئ یو څه هیر کړئ یا یو څه داخل کړئ چې تیر ځل خپور شوی و، ځینې وختونه دا روښانه نه وي چې د پلټ غوښتنې طبقه بندي کول څه دي - ایا دا یو ځانګړتیا یا د بګ حل، یا د ترمیم ازموینې، یا یو څه زیربنا

د 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'

اوس هر ډول پل - غوښتنه باید د یوې ټاګ سره نښه شي: ډول: فکس، ډول: ځانګړتیاوې، ډول: اسناد، ډول: ازموینې، ډول: ترتیب.

د پلولو غوښتنو اتومات تشریح

له هغه وخته چې موږ داسې موضوع ته د پلې غوښتنې سره د اغیزمن کار په توګه اشاره وکړه، دا د لیبلر په څیر د داسې عمل په اړه د خبرو کولو ارزښت لري، دا په 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/**"

زه د هغه عمل په جوړه کولو کې بریالی نه شوم چې په اتوماتيک ډول لیبلونه د پل په غوښتنو کې د عمل سره ځای په ځای کوي چې د اړتیا وړ لیبلونو شتون چیک کوي؛ د میچ لیبل نه غواړي د بوټ لخوا اضافه شوي لیبلونه وګوري. داسې ښکاري چې خپل عمل ولیکئ چې دواړه مرحلې سره یوځای کوي. مګر حتی پدې فورمه کې دا کارول خورا اسانه دي؛ تاسو اړتیا لرئ د لیست څخه لیبل غوره کړئ کله چې د پلې غوښتنې رامینځته کړئ.

دا د ځای پرځای کولو وخت دی

ما د ګیټ هب عملونو له لارې د ګمارنې ډیری اختیارونه هڅه وکړه (د ssh له لارې ، د scp له لارې ، او د docker-hub په کارولو سره) ، او زه کولی شم ووایم چې ، ډیری احتمال ، تاسو به سرور ته د بائنری اپلوډ کولو لاره ومومئ ، پرته لدې چې ستاسو پایپ لاین څومره خراب وي. دی.

ما په یو ځای کې د ټول زیربنا ساتلو اختیار خوښ کړ، نو راځئ چې وګورو چې څنګه د GitHub پیکجونو ځای پرځای کول (دا د بائنری مینځپانګې، npm، جار، ډاکر لپاره ذخیره ده).

د ډاکر عکس جوړولو لپاره سکریپټ او په 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 Packages Repository ته خپور کړئ:

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

د عکس نسخې په ګوته کولو لپاره ، موږ د ژمنې د SHA هش څخه لومړۍ عددونه کاروو - GITHUB_SHA دلته هم لنډیزونه شتون لري ، که تاسو دا ډول جوړونه نه یوازې په ماسټر کې د یوځای کیدو پر مهال رامینځته کوئ ، بلکه د پلې غوښتنې رامینځته کولو سره سم. پیښه ، نو SHA ممکن د هغه هش سره سمون ونلري چې موږ یې د ګیټ تاریخ کې ګورو ، ځکه چې کړنې/چیک آوټ عمل خپل ځانګړی هش رامینځته کوي ترڅو په PR کې د بندیدو عملونو مخه ونیسي.

که هرڅه سم کار وکړي ، نو بیا په ذخیره کې د کڅوړو برخه (https://github.com/antkorwin/github-actions/packages) پرانستل ، تاسو به د نوي ډاکر عکس وګورئ:

هلته تاسو کولی شئ د ډاکر عکس د نسخو لیست هم وګورئ.

ټول هغه څه چې پاتې دي زموږ د سرور تنظیم کول دي ترڅو د دې راجسټری سره کار وکړي او خدمت بیا پیل کړي. زه به شاید په دې اړه وغږیږم چې دا څنګه د سیسټم له لارې بل ځل ترسره کړم.

څارنه

راځئ چې د 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"}

ټول هغه څه چې موږ ورته اړتیا لرو د کرون په کارولو سره د سرور چک کولو لپاره د دندې لیکلو ته اړتیا لرو ، او که ناڅاپه دا موږ ته ځواب نه راکوي ، نو موږ به د ټیلیګرام له لارې خبرتیا واستوو.

لومړی، راځئ چې معلومه کړو چې څنګه د کرون کاري فلو چلول کیږي:

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

دا ساده دی ، زه حتی باور نشم کولی چې په ګیتوب کې تاسو کولی شئ داسې پیښې رامینځته کړئ چې په هیڅ ډول په ویب هکس کې مناسب نه وي. جزئیات په اسنادو کې دي: 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"

لومړی، موږ په یو متغیر کې خوندي کوو هغه څه چې سرور غوښتنې ته ځواب ووایه، په بل ګام کې موږ ګورو چې وضعیت 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 }}

موږ یوازې ټیلیګرام ته لیږو که چیرې عمل په تیر مرحله کې ناکام شو. د پیغام لیږلو لپاره موږ د ایپل بوای/ټلیګرام-ایکشن کاروو؛ تاسو کولی شئ په اسنادو کې د بوټ نښه او چیټ ID ترلاسه کولو څرنګوالي په اړه ولولئ: github.com/appleboy/telegram-action

د ګیتوب په رازونو کې لیکل مه هیروئ: د سرور لپاره یو آر ایل او د ټیلیګرام بوټ لپاره ټوکن.

د بونس ټریک - د سست لپاره JIRA

ما وعده کړې وه چې موږ به بیرته JIRA ته راستانه شو، او موږ بیرته راستانه شوي یو. په سلګونو ځله ما په سټینډ اپ کې وضعیت لیدلی کله چې پراختیا کونکو یو فیچر رامینځته کړی ، یوه څانګه ضمیمه کړې ، مګر مسله په JIRA کې راښکته کول هیر شوي. البته، که دا ټول په یو ځای کې ترسره شوي وي، دا به اسانه وي، مګر په حقیقت کې موږ په IDE کې کوډ لیکو، څانګې یې په bitbucket یا GitHub کې ضمیمه کوو، او بیا یې کارونه جیرا ته کشوو، د دې لپاره موږ اړتیا لرو چې نوې وینډوز خلاص کړو. ، ځینې وختونه بیا ننوتل او داسې نور. کله چې تاسو په بشپړ ډول په یاد ولرئ چې تاسو بل څه کولو ته اړتیا لرئ، نو بیا د بورډ پرانیستلو لپاره هیڅ معنی نشته. د پایلې په توګه، په سهار کې په سټینډ اپ کې تاسو اړتیا لرئ چې د کاري بورډ تازه کولو وخت مصرف کړئ.

GitHub به موږ سره پدې معمول کار کې هم مرسته وکړي؛ د پیل کونکو لپاره ، موږ کولی شو مسلې په اوتومات ډول د code_review کالم کې راوباسئ کله چې موږ د پلولو غوښتنه وسپارو. ټول هغه څه چې تاسو یې کولو ته اړتیا لرئ د څانګې نومولو کنوانسیون تعقیب کړئ:

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

د مثال په توګه ، که د پروژې کیلي "GitHub کړنې" GA وي ، نو بیا GA-8-jira-bot د GA-8 دندې پلي کولو لپاره یوه څانګه کیدی شي.

د JIRA سره ادغام د اتلسیانو څخه د عملونو له لارې کار کوي، دوی بشپړ ندي، زه باید ووایم چې ځینې یې زما لپاره کار نه کوي. مګر موږ به یوازې د هغو په اړه بحث وکړو چې یقینا کار کوي او په فعاله توګه کارول کیږي.

لومړی تاسو اړتیا لرئ د عمل په کارولو سره 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 په کارولو سره ورته شی لیکلی و، ځکه چې د اتلاسیان دا عمل نه غوښتل زما په پروژه کې په هیڅ ډول کار وکړي. د دې معلومولو لپاره چې هلته څه غلط وو - د خپلو لاسونو سره ورته کار کولو څخه ډیر اوږد.

ټول هغه څه چې پاتې دي دا دي چې دنده د "کوډ بیاکتنې" کالم ته انتقال کړئ کله چې د پلټ غوښتنه رامینځته کړئ:

  - 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 ذخیره کې پوسټ کړئ.
• د غونډې لپاره د هدف پلیټ فارم غوره کول: لینکس ، ماک او ایس ، وینډوز خورا په زړه پوري ب featureه ده.
• د ګیتوب کڅوړې یو عالي شی دی ، دا مناسب دی چې ټول زیربناوې په یو ځای کې وساتئ ، تاسو اړتیا نلرئ د مختلف کړکیو له لارې سرف وکړئ ، هرڅه د یو یا دوه ماوس کلیکونو په ریاس کې دي او په بشپړ ډول د GitHub عملونو سره مدغم شوي. په وړیا نسخه کې د ډاکر راجسټری ملاتړ هم ښه ګټه ده.
• GitHub د جوړونې لاګونو کې رازونه پټوي، نو د پاسورډونو او ټوکنونو ذخیره کولو لپاره یې کارول دومره ډارونکي ندي. زما د ټولو تجربو په جریان کې، زه هیڅکله د دې توان نه لرم چې په کنسول کې په خپل خالص شکل کې راز وګورم.
• د خلاصې سرچینې پروژې لپاره وړیا

ضمیمه:

• YML، ښه، زه هغه نه خوښوم. کله چې د داسې جریان سره کار کوئ ، ترټولو عام ژمن پیغام چې زه یې لرم هغه د "YML فارمیټ فکس کړئ" دی ، بیا تاسو هیر کړئ چې چیرې یو ټب ځای په ځای کړئ ، یا تاسو دا په غلط لیک کې ولیکئ. په عموم کې، د پروټریکټر او حاکم سره د سکرین مخې ته ناست ترټولو خوندور تجربه نه ده.
• DEBUG، د ژمنو سره د جریان ډیبګ کول، د بیارغونې چلول، او کنسول ته محصول ورکول تل اسانه ندي، مګر دا د "تاسو ډیر شوي" کټګورۍ څخه ډیره ده؛ تاسو د مناسب IDEA سره کار کولو عادت یاست، کله چې تاسو هر څه ډیبګ کولی شئ .
• تاسو کولی شئ خپل عمل په هر څه باندې ولیکئ که تاسو دا په ډاکر کې وپلټئ ، مګر یوازې جاواسکریپټ په اصلي ډول ملاتړ کیږي ، البته دا د خوند خبره ده ، مګر زه به د js پرځای بل څه غوره کړم.

اجازه راکړئ تاسو ته یادونه وکړم چې د ټولو سکریپټونو ذخیره دلته ده: github.com/antkorwin/github-actions

راتلونکې اونۍ به زه ورسره پرفارم وکړم راپور د هیزنبګ 2020 پیټر کنفرانس کې. زه به تاسو ته نه یوازې ووایم چې څنګه د ټیسټ ډیټا چمتو کولو پرمهال د غلطیو څخه مخنیوی وکړئ ، بلکه د جاوا غوښتنلیکونو کې د ډیټا سیټونو سره د کار کولو رازونه هم شریک کړئ!

سرچینه: www.habr.com