پرو هوسٽر > بلاگ > انتظاميه > GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

مون کي اڪثر جاوا ۾ تعميراتي منصوبن لاءِ پائپ لائن ٺاهڻي پوندي آهي. ڪڏهن ڪڏهن اهو کليل ذريعو آهي، ڪڏهن ڪڏهن اهو ناهي. مون تازو ئي فيصلو ڪيو ته ڪوشش ڪرڻ جي ڪوشش ڪئي وڃي منهنجي ڪجهه ذخيرن کي ٽريس-سي آءِ ۽ ٽيم سٽي کان گيٽ هب ايڪشنز ڏانهن، ۽ اهو ئي آهي جيڪو ان مان نڪتو.

اسان ڇا خودڪار ڪنداسين؟

پهرين، اسان کي هڪ پروجيڪٽ جي ضرورت آهي جيڪا اسان خودڪار ڪنداسين، اچو ته اسپرنگ بوٽ / جاوا 11 / ميون ۾ هڪ ننڍڙي ايپليڪيشن ٺاهيو. هن آرٽيڪل جي مقصدن لاءِ، اسان کي اپليڪيشن جي منطق ۾ ڪا به دلچسپي نه هوندي؛ ايپليڪيشن جي چوڌاري انفراسٽرڪچر اسان لاءِ اهم آهي، تنهنڪري هڪ سادو REST API ڪنٽرولر اسان لاءِ ڪافي هوندو.

توهان هتي ذريعن کي ڏسي سگهو ٿا: github.com/antkorwin/github-actions پائپ لائن جي تعمير جا سڀئي مرحلا هن منصوبي لاء پل درخواستن ۾ ظاهر ٿيندا آهن.

JIRA ۽ منصوبه بندي

اهو چوڻ جي قابل آهي ته اسان عام طور تي JIRA کي هڪ مسئلي جي ٽريڪٽر طور استعمال ڪندا آهيون، تنهنڪري اچو ته هن منصوبي لاء هڪ الڳ بورڊ ٺاهيو ۽ اتي پهريون مسئلا شامل ڪريو:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

ٿوري دير کان پوء اسين واپس ڪنداسين جيڪي دلچسپ شيون JIRA ۽ GitHub ميلاپ ۾ پيش ڪري سگھن ٿا.

اسان منصوبي جي اسيمبلي کي خودڪار ڪريون ٿا

اسان جو ٽيسٽ پروجيڪٽ ميون ذريعي ٺاهيو ويو آهي، تنهنڪري ان کي تعمير ڪرڻ بلڪل سادو آهي، اسان کي صرف ايم وي اين صاف پيڪيج جي ضرورت آهي.

Github Actions استعمال ڪندي اهو ڪرڻ لاءِ، اسان کي پنهنجي ڪم جي فلو کي بيان ڪندي مخزن ۾ هڪ فائل ٺاهڻي پوندي، اهو هڪ باقاعده 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 چونڊي سگھون ٿا، حيرت انگيز طور تي، توھان پڻ چونڊي سگھو ٿا Mac OS، پر پرائيويٽ مخزن تي اھو ڪافي قيمتي آھي (لينڪس جي مقابلي ۾).

فائدا توهان کي ٻين عملن کي ٻيهر استعمال ڪرڻ جي اجازت ڏئي ٿي، مثال طور، ايڪشن/ سيٽ اپ-جاوا ايڪشن استعمال ڪندي اسان ماحول کي جاوا 11 لاءِ انسٽال ڪريون ٿا.

جي مدد سان سان اسان وضاحت ڪري سگھون ٿا پيرا ميٽرز جن سان اسان عمل کي شروع ڪريون ٿا، بنيادي طور تي اھي دليل آھن جيڪي عمل ڏانھن منتقل ڪيا ويندا.

اهو سڀ ڪجهه رهي ٿو Maven سان منصوبي جي تعمير کي هلائڻ لاءِ: run: mvn -B clean package جھنڊو -B چوي ٿو ته اسان کي غير انٽرايڪٽو موڊ جي ضرورت آهي ته جيئن اوچتو مايون اسان کان ڪجهه پڇڻ نه چاهي.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

زبردست! هاڻي، هر دفعي توهان ماسٽر سان واعدو ڪيو، منصوبي جي تعمير شروع ٿيندي.

خودڪار ٽيسٽ لانچ

اسيمبلي سٺي آهي، پر حقيقت ۾، هڪ منصوبي کي محفوظ طور تي گڏ ڪري سگهجي ٿو، پر ڪم نه. تنهن ڪري، ايندڙ قدم ٽيسٽ رن کي خودڪار ڪرڻ آهي. ان کان علاوه، ٽيسٽ پاس ڪرڻ جي نتيجن کي ڏسڻ لاءِ ڪافي آسان آھي جڏھن توھان پي آر جو جائزو وٺو - توھان کي پڪ ڄاڻو ٿا ته ٽيسٽ پاس ٿي ويا آھن ۽ ڪو به ضم ڪرڻ کان اڳ پنھنجي شاخ کي هلائڻ نه وساريو.

اسان ٽيسٽ هلائينداسين جڏهن پل جي درخواست ٺاهي ۽ ماسٽر ۾ ضم ٿي ويندي، ۽ ساڳئي وقت اسان ڪوڊ-ڪوريج تي رپورٽ ٺاهڻ شامل ڪنداسين.

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 ۾ رازن کي محفوظ ڪرڻ لاء هڪ ميکانيزم آهي، اسان اتي لکي سگهون ٿا پاسورڊ / ٽوڪن / ميزبان / يو آر ايل ۽ ٻيو ڊيٽا جيڪو ذخيرو ڪوڊ بيس ۾ شامل نه ڪيو وڃي.

توهان GitHub تي مخزن جي سيٽنگن ۾ رازن ۾ هڪ متغير شامل ڪري سگهو ٿا:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

توھان حاصل ڪري سگھو ٿا ٽوڪن تي codecov.io GitHub ذريعي اختيار ڪرڻ کان پوء، عوامي منصوبي کي شامل ڪرڻ لاء توهان کي صرف هن طرح جي لنڪ جي پيروي ڪرڻ جي ضرورت آهي: GitHub استعمال ڪندڙ جو نالو/[ريپو نالو]. هڪ خانگي مخزن پڻ شامل ڪري سگھجي ٿو؛ هن کي ڪرڻ لاءِ، توهان کي Github ۾ ايپليڪيشن کي ڪوڊڪوف حق ڏيڻ جي ضرورت آهي.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

جيڪوڪو پلگ ان کي 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>

هاڻي ڪوڊڪوف بوٽ اسان جي هر پل جي درخواستن ۾ داخل ڪندو ۽ ڪوريج تبديلي گراف شامل ڪندو:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

اچو ته هڪ جامد تجزيه ڪندڙ شامل ڪريو

منهنجي اڪثر اوپن سورس منصوبن ۾ آئون استعمال ڪريان ٿو سونار بادل جامد ڪوڊ جي تجزيي لاءِ، اهو 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 ٺاهي ٿو، جنهن جي مدد سان سونار ڪلائوڊ [bot] گٽ ۾ لاگ ان ٿيڻ جي قابل هوندو ته جيئن اسان کي پل جي درخواستن ۾ پيغام موڪلجي.

Dsonar.projectKey - سونار ۾ پروجيڪٽ جو نالو، توھان ان کي پروجيڪٽ سيٽنگن ۾ ڏسي سگھو ٿا.

Dsonar.organization - تنظيم جو نالو GitHub کان.

اسان هڪ ڇڪڻ جي درخواست ڪريون ٿا ۽ انتظار ڪريون ٿا سونار ڪلائوڊ [بوٽ] تبصرن ۾ اچڻ لاءِ:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

رسيد مينيجمينٽ

تعمير ترتيب ڏني وئي آھي، ٽيسٽ ھليو ويو آھي، ۽ اسان ھڪڙي جاري ڪري سگھون ٿا. اچو ته ڏسو ته ڪيئن GitHub ڪارناما جاري ڪري سگھن ٿا انتظام تمام آسان.

ڪم تي، مون وٽ پراجيڪٽ آهن جن جو ڪوڊ بيس بٽ بڪٽ ۾ آهي (هر شي ان ڪهاڻي ۾ آهي ”مان ڏينهن ۾ بٽ بڪٽ تي لکندو آهيان، رات جو گيٽ هب تي ڪم ڪندو آهيان“). بدقسمتي سان، bitbucket وٽ تعمير ٿيل رليز مينيجمينٽ جا اوزار نه آهن. هي هڪ مسئلو آهي، ڇاڪاڻ ته هر رليز لاءِ توهان کي دستي طور سنگم ۾ هڪ صفحو ٺاهڻو پوندو ۽ رليز ۾ شامل سموريون خاصيتون اُتي اڇلائڻيون پونديون آهن، ذهن جي محلات مان ڳولا ڪرڻي پوندي آهي، جيرا ۾ ڪم، مخزن ۾ ڪم ڪرڻا هوندا آهن. غلطي ڪرڻ جا ڪيترائي موقعا آھن، توھان ڪجھ وساري سگھو ٿا يا ڪجھ داخل ڪري سگھو ٿا جيڪو اڳ ۾ ئي آخري ڀيرو جاري ڪيو ويو ھو، ڪڏھن ڪڏھن اھو واضح نه ٿيندو آھي ته ڪھڙي قسم جي ڇڪڻ واري درخواست کي درجه بندي ڪرڻ گھرجي جيئن - ڇا اھو ھڪڙو خصوصيت آھي يا بگ فڪس، يا ايڊيٽنگ ٽيسٽ، يا ڪجهه بنيادي ڍانچي.

GitHub ڪارناما اسان جي مدد ڪيئن ڪري سگھن ٿا؟ ھڪڙو وڏو عمل آھي - رليز ڊرافٽ، اھو توھان کي اجازت ڏئي ٿو رليز نوٽس فائل ٽيمپليٽ سيٽ ڪرڻ لاءِ پل جي درخواستن جي ڪيٽيگريز کي سيٽ ڪرڻ لاءِ ۽ پاڻمرادو انھن کي رليز نوٽس فائل ۾ گروپ ڪريو:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

رپورٽ قائم ڪرڻ لاءِ مثال ٽيمپليٽ (.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 }}

ھاڻي ھاڻي کان سڀ پل درخواستون پاڻمرادو رليز نوٽس ۾ گڏ ڪيون وينديون - جادو!

هتي سوال پيدا ٿي سگهي ٿو: ڇا جيڪڏهن ڊولپرز پي آر ۾ ٽيگ لڳائڻ وساريندا؟ پوء اهو واضح ناهي ته ان کي ڪهڙي درجي ۾ رکڻو پوندو، ۽ ٻيهر توهان کي ان سان دستي طور تي معاملو ڪرڻو پوندو، هر پي آر سان الڳ الڳ. هن مسئلي کي حل ڪرڻ لاء، اسان هڪ ٻيو عمل استعمال ڪري سگهون ٿا - ليبل تصديق ڪندڙ - اهو پل جي درخواست تي ٽيگ جي موجودگي لاء چيڪ ڪري ٿو. جيڪڏهن گهربل ٽيگ نه آهن، پوء چيڪ ناڪام ٿي ويندو ۽ اسان ان بابت اسان جي پل درخواست ۾ هڪ پيغام ڏسندا.

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'

ھاڻي ڪنھن به پل-درخواست کي ھڪڙي ھڪڙي ٽيگ سان نشان ھڻڻ گھرجي: قسم: ٺيڪ، قسم: خاصيتون، قسم: دستاويز، قسم: ٽيسٽ، قسم: ترتيب.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

ڇڪڻ جي درخواستن جي خودڪار تشريح

جيئن ته اسان هڪ اهڙي موضوع کي ڇڪيو آهي جيئن ڇڪڻ جي درخواستن سان مؤثر ڪم، اهو هڪ اهڙي عمل بابت ڳالهائڻ جي قابل آهي جيئن ليبلر، اهو پي آر ۾ ٽيگ رکي ٿو جنهن جي بنياد تي فائلون تبديل ڪيون ويون آهن. مثال طور، اسان نشان لڳائي سگھون ٿا [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/**"

مان ان عمل کي جوڙڻ ۾ ڪامياب نه ٿيس جيڪو خودڪار طريقي سان پُل درخواستن ۾ ليبل رکي ٿو ان عمل سان جيڪو چيڪ ڪري ٿو گهربل ليبلز جي موجودگيءَ لاءِ؛ ميچ-ليبل بوٽ پاران شامل ڪيل ليبل ڏسڻ نٿو چاهي. اهو توهان جي پنهنجي عمل کي لکڻ آسان لڳي ٿو جيڪو ٻنهي مرحلن کي گڏ ڪري ٿو. پر اڃا به هن فارم ۾ اهو استعمال ڪرڻ بلڪل آسان آهي؛ توهان کي فهرست مان هڪ ليبل چونڊڻ جي ضرورت آهي جڏهن پل جي درخواست ٺاهيندي.

اهو وقت لڳائڻ جو وقت آهي

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

مون GitHub Actions ذريعي (ssh ذريعي، scp ذريعي، ۽ docker-hub استعمال ڪندي) ڪيترن ئي ترتيب ڏيڻ جي آپشنز جي ڪوشش ڪئي، ۽ مان چئي سگهان ٿو ته، گهڻو ڪري، توهان کي سرور تي بائنري اپلوڊ ڪرڻ جو هڪ طريقو ملندو، توهان جي پائپ لائن ڪيتري به خراب ناهي. آهي.

مون سڄي انفراسٽرڪچر کي هڪ جاءِ تي رکڻ جو آپشن پسند ڪيو، تنهنڪري اچو ته ڏسون ته GitHub پيڪيجز کي ڪيئن لڳايو وڃي (هي بائنري مواد، npm، jar، 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 فائل ٺاهڻ جي ضرورت آهي، جنهن کان پوء اسان حساب ڪريون ٿا گيٽ هب ڊاکر رجسٽري ڏانهن رستو ۽ اسان جي تصوير جو نالو. هتي ڪجھ چالون آهن جيڪي اسان کي اڃا تائين نظر نه آيون آهن:

  • ھڪڙي تعمير جھڙوڪ: 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 هتي پڻ nuances آهن، جيڪڏهن توهان اهڙيون تعميرات نه صرف ماسٽر ۾ ضم ٿيڻ وقت، پر پل جي درخواست جي تخليق جي مطابق پڻ. واقعي، پوءِ SHA شايد هيش سان نه ملي سگهي جيڪا اسان گٽ جي تاريخ ۾ ڏسون ٿا، ڇاڪاڻ ته عمل/چڪ آئوٽ عمل پي آر ۾ ڊيڊ لاڪنگ عملن کان بچڻ لاءِ پنهنجو منفرد هيش ٺاهي ٿو.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

جيڪڏهن هر شي چڱي طرح ڪم ڪيو، پوء کوليو پيڪيجز سيڪشن (https://github.com/antkorwin/github-actions/packages) مخزن ۾، توهان هڪ نئين ڊاکر تصوير ڏسندا:

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

اتي توھان پڻ ڏسي سگھو ٿا نسخن جي ھڪڙي فهرست ڊاکر تصوير.

باقي رهي ٿو اسان جي سرور کي ترتيب ڏيڻ لاءِ هن رجسٽري سان ڪم ڪرڻ ۽ سروس کي ٻيهر شروع ڪرڻ. مان شايد انهي بابت ڳالهائيندس ته اهو ڪيئن ڪجي سسٽم ذريعي ڪنهن ٻئي وقت.

مانيٽرنگ

اچو ته هڪ سادي اختيار تي نظر رکون ته ڪيئن ڪجي صحت جي چڪاس اسان جي ايپليڪيشن لاءِ 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 * * * *'

اهو سادو آهي، مان اهو به يقين نه ٿو ڪري سگهان 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"

پهرين، اسان هڪ متغير ۾ محفوظ ڪريون ٿا جيڪو سرور درخواست جو جواب ڏنو، ايندڙ قدم ۾ اسان چيڪ ڪريون ٿا ته اسٽيٽس 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؛ توهان پڙهي سگهو ٿا ته ڪيئن حاصل ڪجي بوٽ ٽوڪن ۽ چيٽ آئي ڊي دستاويزن ۾: github.com/appleboy/telegram-action

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

Github تي رازن ۾ لکڻ نه وساريو: سرور لاءِ URL ۽ ٽيليگرام بوٽ لاءِ ٽوڪن.

بونس ٽريڪ - سست لاء JIRA

مون واعدو ڪيو هو ته جيئرا واپس وينداسين، ۽ موٽي آيا آهيون. سوين ڀيرا مون اسٽينڊ اپ تي هڪ صورتحال جو مشاهدو ڪيو آهي جڏهن ڊولپرز هڪ فيچر ٺاهيو، هڪ شاخ کي ضم ڪيو، پر مسئلو کي JIRA ۾ ڇڪڻ وساري ڇڏيو. يقينن، جيڪڏهن اهو سڀ ڪجهه هڪ جڳهه تي ڪيو وڃي ها ته اهو آسان ٿي وڃي ها، پر حقيقت ۾ اسان IDE ۾ ڪوڊ لکندا آهيون، شاخن کي bitbucket يا GitHub ۾ ضم ڪندا آهيون، ۽ پوء ٽاسڪ کي جيرا ۾ ڇڪيندا آهيون، ان لاء اسان کي نئين ونڊوز کولڻ جي ضرورت آهي. ، ڪڏهن وري لاگ ان ٿيو وغيره وغيره. جڏهن توهان مڪمل طور تي ياد ڪيو ته توهان کي اڳتي وڌڻ جي ضرورت آهي، پوء بورڊ کي ٻيهر کولڻ جو ڪو به مقصد ناهي. نتيجي طور، صبح جو هڪ اسٽينڊ اپ تي توهان کي وقت گذارڻ جي ضرورت آهي ٽاسڪ بورڊ کي اپڊيٽ ڪرڻ.

GitHub به اسان جي هن معمولي ڪم ۾ مدد ڪندو؛ شروعات ڪندڙن لاءِ، اسان مسئلا پاڻمرادو ڇڪي سگھون ٿا code_review ڪالمن ۾ جڏهن اسان هڪ پل جي درخواست جمع ڪريون ٿا. توهان سڀني کي ڪرڻو آهي شاخ جي نالي جي ڪنوينشن تي عمل ڪريو:

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

مثال طور، جيڪڏهن پروجيڪٽ جي اهم "GitHub عمل" 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 تي ان لاءِ هڪ خاص عمل آهي، بس ان جي ضرورت آهي مسئلي جي ID جي حاصل ڪيل پوئين مرحلي ۾ ۽ اجازت جي JIRA ۾ جيڪا اسان مٿي ڪئي آهي.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

ساڳئي طريقي سان، توهان ڪمن کي ڇڪي سگهو ٿا جڏهن ماسٽر ۾ ضم ٿي، ۽ GitHub ورڪ فلو کان ٻيا واقعا. عام طور تي، اهو سڀ ڪجهه توهان جي تخيل تي منحصر آهي ۽ معمولي عمل کي خودڪار ڪرڻ جي خواهش.

پهچڻ

جيڪڏهن توهان کلاسک DEVOPS آرياگرام کي ڏسو، اسان سڀني مرحلن کي ڍڪي ڇڏيو آهي، سواء شايد هلائڻ جي، منهنجو خيال آهي ته جيڪڏهن توهان ڪوشش ڪندا، توهان مارڪيٽ ۾ ڪجهه عمل ڳولي سگهو ٿا هيلپ ڊيسڪ سسٽم سان انضمام لاء، تنهنڪري اسان سمجهون ٿا ته پائپ لائن ڦري وئي. ان جي استعمال جي بنياد تي مڪمل طور تي ۽ نتيجو ڪڍي سگهجي ٿو.

GitHub عملن سان دوزخ جا حلقا (جاوا پروجيڪٽ لاءِ CI/CD پائيپ لائين تعمير ڪرڻ)

پرو:

  • سڀني موقعن لاءِ تيار ڪيل ڪارناما سان مارڪيٽ، هي تمام سٺو آهي. انھن مان گھڻا ۾، توھان پڻ ڏسي سگھوٿا ماخذ ڪوڊ کي سمجھڻ لاءِ ته ڪيئن ھڪڙو ساڳيو مسئلو حل ڪجي يا مضمون جي درخواست پوسٽ ڪريو ليکڪ کي سڌو GitHub مخزن ۾.
  • اسيمبليءَ لاءِ ٽارگيٽ پليٽ فارم چونڊڻ: لينڪس، ميڪ او ايس، ونڊوز ڪافي هڪ دلچسپ خصوصيت آهي.
  • Github Packages هڪ وڏي شيءِ آهي، سڄي انفراسٽرڪچر کي هڪ جاءِ تي رکڻ آسان آهي، توهان کي مختلف ونڊوز ذريعي سرفنگ ڪرڻ جي ضرورت ناهي، هر شيءِ هڪ يا ٻه ماؤس ڪلڪن جي ريڊيس جي اندر آهي ۽ مڪمل طور تي GitHub عملن سان ضم ٿيل آهي. ڊاکر رجسٽري سپورٽ مفت ورزن ۾ پڻ هڪ سٺو فائدو آهي.
  • GitHub تعمير لاگز ۾ راز لڪائي ٿو، تنهنڪري پاسورڊ ۽ ٽوڪن کي ذخيرو ڪرڻ لاء استعمال ڪندي اهو خوفناڪ ناهي. منهنجي سڀني تجربن دوران، مون ڪڏهن به ان راز کي ان جي خالص روپ ۾ ڪنسول ۾ ڏسي نه سگهيو.
  • اوپن سورس منصوبن لاءِ مفت

ڪن

  • YML، چڱو، مان هن کي پسند نٿو ڪريان. جڏهن اهڙي وهڪري سان ڪم ڪري رهيا آهيو، مون وٽ سڀ کان وڌيڪ عام ڪمٽ پيغام آهي "فيڪس yml فارميٽ"، ڪڏهن ڪڏهن توهان هڪ ٽيب کي ڪٿي رکڻ وساريندا آهيو، ڪڏهن ڪڏهن توهان ان کي غلط لائن تي لکندا آهيو. عام طور تي، اسڪرين جي سامهون ويٺي هڪ پروڪٽر ۽ حڪمران سان گڏ سڀ کان وڌيڪ خوشگوار تجربو ناهي.
  • DEBUG، ڪميٽ سان وهڪري کي ڊيبگ ڪرڻ، ٻيهر تعمير ڪرڻ، ۽ ڪنسول ڏانهن آئوٽ ڪرڻ هميشه سولو نه هوندو آهي، پر اهو وڌيڪ آهي ”توهان اوورڊون“ ڪيٽيگري؛ توهان کي استعمال ڪيو ويو آهي ڪم ڪرڻ لاءِ آسان IDEA سان، جڏهن توهان ڪنهن به شيءِ کي ڊيبگ ڪري سگهو ٿا .
  • توھان پنھنجي عمل کي ڪنھن به شيءِ تي لکي سگھوٿا جيڪڏھن توھان ان کي ڊاکر ۾ لپايو، پر صرف جاوا اسڪرپٽ مقامي طور تي سپورٽ ڪئي وئي آھي، يقينا اھو ذائقي جو معاملو آھي، پر مان js جي بدران ٻي شيء کي ترجيح ڏيندس.

مون کي توهان کي ياد ڏيارڻ ڏيو ته سڀني اسڪرپٽ سان گڏ مخزن هتي آهي: github.com/antkorwin/github-actions

ايندڙ هفتي مان پرفارم ڪندس رپورٽ Heisenbug 2020 Piter ڪانفرنس ۾. مان توهان کي نه صرف اهو ٻڌايان ٿو ته ڪيئن غلطين کان پاسو ڪجي جڏهن ٽيسٽ ڊيٽا تيار ڪرڻ وقت، پر جاوا ايپليڪيشنن ۾ ڊيٽا سيٽ سان ڪم ڪرڻ جا راز به شيئر ڪريو!

جو ذريعو: www.habr.com