GitHub क्रियाओं के साथ नरक के चक्र (जावा प्रोजेक्ट के लिए CI/CD पाइपलाइन का निर्माण)

मुझे अक्सर जावा में परियोजनाओं के निर्माण के लिए पाइपलाइन बनानी पड़ती है। कभी-कभी यह खुला स्रोत होता है, कभी-कभी यह नहीं होता है। मैंने हाल ही में अपनी कुछ रिपॉजिटरी को ट्रैविस-सीआई और टीमसिटी से गिटहब एक्शन में स्थानांतरित करने का प्रयास करने का निर्णय लिया, और इससे यही परिणाम निकला।

हम क्या स्वचालित करेंगे?

सबसे पहले, हमें एक प्रोजेक्ट की आवश्यकता है जिसे हम स्वचालित करेंगे, आइए स्प्रिंग बूट/जावा 11/मावेन में एक छोटा एप्लिकेशन बनाएं। इस लेख के प्रयोजनों के लिए, हमें एप्लिकेशन लॉजिक में बिल्कुल भी दिलचस्पी नहीं होगी; एप्लिकेशन के आसपास का बुनियादी ढांचा हमारे लिए महत्वपूर्ण है, इसलिए एक साधारण REST API नियंत्रक हमारे लिए पर्याप्त होगा।

आप यहां स्रोत देख सकते हैं: github.com/antkorwin/github-actions पाइपलाइन निर्माण के सभी चरण इस परियोजना के लिए अनुरोधों में परिलक्षित होते हैं।

जिरा और योजना

यह कहने लायक है कि हम आमतौर पर JIRA को एक समस्या ट्रैकर के रूप में उपयोग करते हैं, तो आइए इस परियोजना के लिए एक अलग बोर्ड बनाएं और वहां पहले अंक जोड़ें:

थोड़ी देर बाद हम इस बात पर लौटेंगे कि JIRA और GitHub संयोजन में कौन सी दिलचस्प चीज़ें पेश कर सकते हैं।

हम प्रोजेक्ट की असेंबली को स्वचालित करते हैं

हमारा परीक्षण प्रोजेक्ट मावेन के माध्यम से बनाया गया है, इसलिए इसे बनाना काफी सरल है, हमें बस एमवीएन क्लीन पैकेज की आवश्यकता है।

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 — यह उस इवेंट का विवरण है जिस पर हमारी स्क्रिप्ट लॉन्च की जाएगी।

चालू: पुल_अनुरोध/पुश - इंगित करता है कि इस वर्कफ़्लो को हर बार लॉन्च करने की आवश्यकता होती है जब मास्टर को पुश किया जाता है और पुल अनुरोध बनाए जाते हैं।

निम्नलिखित कार्यों का विवरण है (नौकरियों) और निष्पादन चरण (कदम) प्रत्येक कार्य के लिए।

इससे संचालित - यहां हम लक्ष्य ओएस का चयन कर सकते हैं, आश्चर्यजनक रूप से, आप मैक ओएस भी चुन सकते हैं, लेकिन निजी रिपॉजिटरी पर यह काफी महंगा है (लिनक्स की तुलना में)।

का उपयोग करता है आपको अन्य क्रियाओं का पुन: उपयोग करने की अनुमति देता है, उदाहरण के लिए, क्रियाओं/सेटअप-जावा क्रिया का उपयोग करके हम जावा 11 के लिए पर्यावरण स्थापित करते हैं।

के द्वारा साथ में हम उन मापदंडों को निर्दिष्ट कर सकते हैं जिनके साथ हम कार्रवाई शुरू करते हैं, अनिवार्य रूप से ये वे तर्क हैं जिन्हें कार्रवाई में पारित किया जाएगा।

मेवेन के साथ प्रोजेक्ट बिल्ड को चलाने के लिए जो कुछ बचा है वह है: run: mvn -B clean package झंडा -B कहता है कि हमें एक गैर-संवादात्मक मोड की आवश्यकता है ताकि मावेन अचानक हमसे कुछ न पूछना चाहे

महान! अब, हर बार जब आप मास्टर के प्रति प्रतिबद्ध होते हैं, तो प्रोजेक्ट का निर्माण शुरू हो जाता है।

स्वचालित परीक्षण लॉन्च

असेंबली अच्छी है, लेकिन वास्तव में, एक प्रोजेक्ट को सुरक्षित रूप से असेंबल किया जा सकता है, लेकिन काम नहीं किया जा सकता। इसलिए, अगला कदम परीक्षण रन को स्वचालित करना है। इसके अलावा, जब आप पीआर समीक्षा करते हैं तो परीक्षण पास करने के परिणामों को देखना काफी सुविधाजनक होता है - आप निश्चित रूप से जानते हैं कि परीक्षण पास हो जाते हैं और कोई भी मर्ज करने से पहले अपनी शाखा चलाना नहीं भूलता है।

हम पुल अनुरोध बनाते समय परीक्षण चलाएंगे और मास्टर में विलय करेंगे, और साथ ही हम कोड-कवरेज पर एक रिपोर्ट का निर्माण जोड़ देंगे।

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 के माध्यम से प्राधिकरण के बाद, एक सार्वजनिक प्रोजेक्ट जोड़ने के लिए आपको बस इस तरह एक लिंक का पालन करना होगा: 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>

अब कोडकोव बॉट हमारे प्रत्येक पुल अनुरोध में प्रवेश करेगा और एक कवरेज परिवर्तन ग्राफ जोड़ देगा:

आइए एक स्थैतिक विश्लेषक जोड़ें

अपने अधिकांश ओपन सोर्स प्रोजेक्ट्स में मैं स्थिर कोड विश्लेषण के लिए सोनार क्लाउड का उपयोग करता हूं, ट्रैविस-सीआई से कनेक्ट करना काफी आसान है। इसलिए ऐसा करने के लिए GitHub Actions पर माइग्रेट करते समय यह एक तार्किक कदम है। एक्शन मार्केट एक अच्छी चीज़ है, लेकिन इस बार इसने मुझे थोड़ा निराश किया, क्योंकि आदत से मुझे वह एक्शन मिल गया जिसकी मुझे ज़रूरत थी और इसे वर्कफ़्लो में जोड़ दिया। लेकिन यह पता चला कि सोनार मावेन या ग्रेडेल पर परियोजनाओं के विश्लेषण के लिए एक कार्रवाई के माध्यम से काम करने का समर्थन नहीं करता है। बेशक, यह दस्तावेज़ में लिखा है, लेकिन इसे पढ़ता कौन है?!

यह किसी क्रिया के माध्यम से संभव नहीं है, इसलिए हम इसे एमवीएन प्लगइन के माध्यम से करेंगे:

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 - पर प्राप्त किया जा सकता है सोनारक्लाउड.आईओ और आपको इसे रहस्यों में दर्ज करने की आवश्यकता है। GITHUB_टोकन - यह एक अंतर्निहित टोकन है जिसे GitHub जेनरेट करता है, जिसकी मदद से सोनारक्लाउड [बॉट] हमें पुल अनुरोधों में संदेश छोड़ने के लिए Git में लॉग इन करने में सक्षम होगा।

Dsonar.projectKey - सोनार में प्रोजेक्ट का नाम, आप इसे प्रोजेक्ट सेटिंग्स में देख सकते हैं।

Dsonar.संगठन - 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 }}

अब से सभी पुल अनुरोध स्वचालित रूप से रिलीज़ नोट्स में एकत्र किए जाएंगे - जादू!

यहां सवाल उठ सकता है: क्या होगा यदि डेवलपर्स पीआर में टैग लगाना भूल जाएं? फिर यह स्पष्ट नहीं है कि इसे किस श्रेणी में रखा जाए, और फिर से आपको प्रत्येक पीआर के साथ अलग से मैन्युअल रूप से निपटना होगा। इस समस्या को ठीक करने के लिए, हम एक अन्य क्रिया - लेबल सत्यापनकर्ता का उपयोग कर सकते हैं - यह पुल अनुरोध पर टैग की उपस्थिति की जाँच करता है। यदि कोई आवश्यक टैग नहीं हैं, तो चेक विफल हो जाएगा और हम अपने पुल अनुरोध में इसके बारे में एक संदेश देखेंगे।

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/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 पैकेजों को कैसे तैनात किया जाए (यह बाइनरी सामग्री, एनपीएम, जार, डॉकर के लिए एक भंडार है)।

डॉकर छवि बनाने और उसे 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 docker रजिस्ट्री के पथ और हमारी छवि के नाम की गणना करते हैं। यहां कुछ तरकीबें हैं जिनसे हम अभी तक परिचित नहीं हुए हैं:

• एक निर्माण जैसे: echo "::set-output name=NAME::VALUE" आपको वर्तमान चरण में एक चर का मान सेट करने की अनुमति देता है, ताकि इसे अन्य सभी चरणों में पढ़ा जा सके।
• आप इस चरण के पहचानकर्ता के माध्यम से पिछले चरण में सेट किए गए वेरिएबल का मान प्राप्त कर सकते हैं: ${{steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• मानक GITHUB_REPOSITORY वैरिएबल रिपॉजिटरी और उसके मालिक ("मालिक/रेपो-नाम") का नाम संग्रहीत करता है। रिपॉजिटरी के नाम को छोड़कर इस लाइन से सब कुछ काटने के लिए, हम बैश सिंटैक्स का उपयोग करेंगे: ${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 उस हैश से मेल नहीं खा सकता है जिसे हम गिट इतिहास में देखते हैं, क्योंकि पीआर में गतिरोध कार्यों से बचने के लिए क्रियाएं/चेकआउट कार्रवाई अपना स्वयं का अद्वितीय हैश बनाती है।

यदि सब कुछ ठीक रहा, तो रिपॉजिटरी में पैकेज अनुभाग (https://github.com/antkorwin/github-actions/packages) खोलने पर, आपको एक नई डॉकर छवि दिखाई देगी:

वहां आप डॉकर छवि के संस्करणों की एक सूची भी देख सकते हैं।

इस रजिस्ट्री के साथ काम करने के लिए हमारे सर्वर को कॉन्फ़िगर करना और सेवा को पुनरारंभ करना बाकी है। सिस्टमड के माध्यम से इसे कैसे करें, इसके बारे में मैं शायद अगली बार बात करूंगा।

निगरानी

आइए GitHub Actions का उपयोग करके हमारे एप्लिकेशन के लिए स्वास्थ्य जांच कैसे करें, इस पर एक सरल विकल्प देखें। हमारे बूट एप्लिकेशन में एक एक्चुएटर है, इसलिए हमें इसकी स्थिति की जांच करने के लिए एपीआई लिखने की भी आवश्यकता नहीं है; हमने आलसी लोगों के लिए पहले ही सब कुछ कर लिया है। आपको बस होस्ट को खींचने की जरूरत है: 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

आइए कर्ल के माध्यम से सर्वर स्थिति मैन्युअल रूप से जांचें:

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

हम टेलीग्राम तभी भेजते हैं जब पिछले चरण में कार्रवाई विफल हो जाती है। संदेश भेजने के लिए हम ऐप्पलबॉय/टेलीग्राम-एक्शन का उपयोग करते हैं; आप दस्तावेज़ में बॉट टोकन और चैट आईडी कैसे प्राप्त करें, इसके बारे में पढ़ सकते हैं: github.com/appleboy/telegram-action

जीथब पर रहस्य लिखना न भूलें: सर्वर के लिए यूआरएल और टेलीग्राम बॉट के लिए टोकन।

बोनस ट्रैक - आलसी के लिए JIRA

मैंने वादा किया था कि हम JIRA में लौटेंगे, और हम वापस आ गए हैं। सैकड़ों बार मैंने स्टैंड-अप पर ऐसी स्थिति देखी है जब डेवलपर्स ने एक फीचर बनाया, एक शाखा का विलय किया, लेकिन मुद्दे को जेआईआरए में खींचना भूल गए। बेशक, अगर यह सब एक ही स्थान पर किया जाता, तो यह आसान होता, लेकिन वास्तव में हम आईडीई में कोड लिखते हैं, शाखाओं को बिटबकेट या गिटहब में मर्ज करते हैं, और फिर कार्यों को जिरा में खींचते हैं, इसके लिए हमें नई विंडो खोलने की आवश्यकता होती है , कभी-कभी दोबारा लॉग इन करें आदि। जब आपको पूरी तरह याद है कि आपको आगे क्या करना है, तो बोर्ड को दोबारा खोलने का कोई मतलब नहीं है। परिणामस्वरूप, सुबह स्टैंडअप पर आपको टास्क बोर्ड को अपडेट करने में समय व्यतीत करना पड़ता है।

इस नियमित कार्य में GitHub भी हमारी मदद करेगा; शुरुआत के लिए, जब हम पुल अनुरोध सबमिट करते हैं तो हम मुद्दों को स्वचालित रूप से कोड_रिव्यू कॉलम में खींच सकते हैं। आपको बस शाखा नामकरण परंपरा का पालन करना है:

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

उदाहरण के लिए, यदि प्रोजेक्ट कुंजी "GitHub Actions" GA है, तो GA-8-jira-bot GA-8 कार्य को कार्यान्वित करने के लिए एक शाखा हो सकती है।

जेआईआरए के साथ एकीकरण एटलसियन के कार्यों के माध्यम से काम करता है, वे सही नहीं हैं, मुझे कहना होगा कि उनमें से कुछ ने मेरे लिए बिल्कुल भी काम नहीं किया। लेकिन हम केवल उन्हीं पर चर्चा करेंगे जो निश्चित रूप से काम करते हैं और सक्रिय रूप से उपयोग किए जाते हैं।

सबसे पहले आपको इस क्रिया का उपयोग करके 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 बाज़ार में खोज करते हैं, तो आप इस कार्य के लिए एक कार्रवाई पा सकते हैं, लेकिन मुझे शाखा के नाम का उपयोग करके grep का उपयोग करके वही चीज़ लिखनी पड़ी, क्योंकि एटलसियन की यह कार्रवाई किसी भी तरह से मेरे प्रोजेक्ट पर काम नहीं करना चाहती थी , यह पता लगाने में कि वहां क्या गलत था - अपने हाथों से वही काम करने से ज्यादा समय।

पुल अनुरोध बनाते समय कार्य को "कोड समीक्षा" कॉलम में ले जाना बाकी है:

  - 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 रिपॉजिटरी में लेखक को एक फीचर अनुरोध पोस्ट कर सकते हैं।
• असेंबली के लिए लक्ष्य प्लेटफ़ॉर्म का चयन करना: लिनक्स, मैक ओएस, विंडोज़ काफी दिलचस्प सुविधा है।
• Github पैकेज एक बहुत अच्छी चीज़ है, संपूर्ण बुनियादी ढांचे को एक ही स्थान पर रखना सुविधाजनक है, आपको अलग-अलग विंडो के माध्यम से सर्फ करने की ज़रूरत नहीं है, सब कुछ एक या दो माउस क्लिक के दायरे में है और GitHub क्रियाओं के साथ पूरी तरह से एकीकृत है। निःशुल्क संस्करण में डॉकर रजिस्ट्री समर्थन भी एक अच्छा लाभ है।
• GitHub बिल्ड लॉग में रहस्य छिपाता है, इसलिए पासवर्ड और टोकन संग्रहीत करने के लिए इसका उपयोग करना उतना डरावना नहीं है। अपने सभी प्रयोगों के दौरान, मैं कंसोल में कभी भी रहस्य को उसके शुद्ध रूप में नहीं देख पाया।
• ओपन सोर्स परियोजनाओं के लिए निःशुल्क

विपक्ष:

• वाईएमएल, ठीक है, मैं उसे पसंद नहीं करता। इस तरह के प्रवाह के साथ काम करते समय, मेरे पास सबसे आम प्रतिबद्ध संदेश "वाईएमएल प्रारूप ठीक करें" होता है, फिर आप कहीं टैब रखना भूल जाते हैं, या आप इसे गलत लाइन पर लिखते हैं। सामान्य तौर पर, चांदा और रूलर के साथ स्क्रीन के सामने बैठना सबसे सुखद अनुभव नहीं है।
• DEBUG, कमिट के साथ प्रवाह को डीबग करना, पुनर्निर्माण चलाना, और कंसोल पर आउटपुट करना हमेशा सुविधाजनक नहीं होता है, लेकिन यह "आपने बहुत अधिक काम कर लिया है" श्रेणी का है; आप सुविधाजनक IDEA के साथ काम करने के आदी हैं, जब आप कुछ भी डीबग कर सकते हैं .
• यदि आप इसे डॉकर में लपेटते हैं तो आप किसी भी चीज़ पर अपनी कार्रवाई लिख सकते हैं, लेकिन केवल जावास्क्रिप्ट ही मूल रूप से समर्थित है, बेशक यह स्वाद का मामला है, लेकिन मैं जेएस के बजाय कुछ और पसंद करूंगा।

मैं आपको याद दिला दूं कि सभी लिपियों वाला भंडार यहां है: github.com/antkorwin/github-actions

अगले सप्ताह मैं प्रदर्शन करूंगा रिपोर्ट good हाइजेनबग 2020 पाइटर सम्मेलन में। मैं आपको न केवल यह बताऊंगा कि परीक्षण डेटा तैयार करते समय गलतियों से कैसे बचा जाए, बल्कि जावा अनुप्रयोगों में डेटा सेट के साथ काम करने के अपने रहस्य भी साझा करूंगा!

स्रोत: www.habr.com