GitHub क्रियांसह नरकाची मंडळे (जावा प्रकल्पासाठी CI/CD पाइपलाइन तयार करणे)

जावामध्ये प्रकल्प बांधण्यासाठी मला अनेकदा पाइपलाइन बांधावी लागते. काहीवेळा ते ओपन सोर्स असते, काहीवेळा ते नसते. मी अलीकडेच माझे काही भांडार ट्रॅव्हिस-सीआय आणि टीमसिटी वरून गिटहब ऍक्शनमध्ये हलवण्याचा निर्णय घेतला आणि त्यातूनच पुढे आले.

आम्ही काय स्वयंचलित करू?

प्रथम, आम्हाला एक प्रकल्प हवा आहे जो आम्ही स्वयंचलित करू, चला स्प्रिंग बूट / Java 11 / Maven मध्ये एक छोटा अनुप्रयोग करूया. या लेखाच्या हेतूंसाठी, आम्हाला ऍप्लिकेशन लॉजिकमध्ये अजिबात स्वारस्य नाही; ऍप्लिकेशनच्या सभोवतालची पायाभूत सुविधा आमच्यासाठी महत्त्वाची आहे, म्हणून आमच्यासाठी एक साधा REST API कंट्रोलर पुरेसा असेल.

तुम्ही येथे स्रोत पाहू शकता: github.com/antkorwin/github-actions पाइपलाइन बांधण्याचे सर्व टप्पे या प्रकल्पाच्या पुल विनंत्यांमध्ये दिसून येतात.

जिरा आणि नियोजन

हे सांगण्यासारखे आहे की आम्ही सहसा 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 — हे त्या इव्हेंटचे वर्णन आहे ज्यावर आमची स्क्रिप्ट लॉन्च केली जाईल.

वर: पुल_रिक्वेस्ट/पुश — सूचित करते की प्रत्येक वेळी मास्टरला पुश केले जाते आणि पुल विनंत्या तयार केल्या जातात तेव्हा हा वर्कफ्लो लॉन्च करणे आवश्यक आहे.

खालील कार्यांचे वर्णन आहे (रोजगार) आणि अंमलबजावणीचे टप्पे (पावले) प्रत्येक कार्यासाठी.

चालू आहे - येथे आम्ही लक्ष्य ओएस निवडू शकतो, आश्चर्याची गोष्ट म्हणजे, आपण मॅक ओएस देखील निवडू शकता, परंतु खाजगी भांडारांवर हे खूप महाग आहे (लिनक्सच्या तुलनेत).

वापर तुम्हाला इतर क्रियांचा पुनर्वापर करण्याची अनुमती देते, उदाहरणार्थ, क्रिया/सेटअप-जावा क्रिया वापरून आम्ही 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 }}

चाचण्या कव्हर करण्यासाठी, मी jacoco प्लगइनच्या संयोगाने codecov वापरतो. codecov ची स्वतःची क्रिया आहे, परंतु आमच्या पुल विनंतीसह कार्य करण्यासाठी त्याला टोकन आवश्यक आहे:

${{ secrets.CODECOV_TOKEN }} — आम्ही हे बांधकाम एकापेक्षा जास्त वेळा पाहू, सिक्रेट्स ही GitHub मध्ये गुपिते साठवण्याची एक यंत्रणा आहे, आम्ही तेथे पासवर्ड/टोकन्स/होस्ट/urls आणि इतर डेटा लिहू शकतो जो रेपॉजिटरी कोड बेसमध्ये समाविष्ट केला जाऊ नये.

तुम्ही GitHub वर रेपॉजिटरी सेटिंग्जमध्ये सिक्रेट्समध्ये व्हेरिएबल जोडू शकता:

येथे तुम्हाला टोकन मिळू शकते codecov.io GitHub द्वारे अधिकृतता केल्यानंतर, सार्वजनिक प्रकल्प जोडण्यासाठी तुम्हाला फक्त यासारख्या दुव्याचे अनुसरण करणे आवश्यक आहे: GitHub वापरकर्तानाव/[रेपो नाव]. खाजगी भांडार देखील जोडले जाऊ शकते; हे करण्यासाठी, तुम्हाला Github मधील अनुप्रयोगास codecov अधिकार देणे आवश्यक आहे.

POM फाइलमध्ये jacoco प्लगइन जोडा:

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

आता codecov बॉट आमच्या प्रत्येक पुल विनंत्या प्रविष्ट करेल आणि कव्हरेज बदल आलेख जोडेल:

चला स्थिर विश्लेषक जोडूया

माझ्या बहुतेक ओपन सोर्स प्रोजेक्ट्समध्ये मी स्टॅटिक कोड विश्लेषणासाठी सोनार क्लाउड वापरतो, ट्रॅव्हिस-सीआयशी कनेक्ट करणे खूप सोपे आहे. म्हणून तेच करण्यासाठी 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 व्युत्पन्न करते, ज्याच्या मदतीने सोनारक्लॉड[बॉट] आम्हाला पुल विनंत्यांमध्ये संदेश देण्यासाठी Git मध्ये लॉग इन करण्यास सक्षम असेल.

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

आतापासून सर्व पुल विनंत्या आपोआप रिलीझ नोट्समध्ये गोळा केल्या जातील - जादू!

येथे प्रश्न उद्भवू शकतो: विकासक पीआरमध्ये टॅग टाकण्यास विसरले तर? मग ते कोणत्या श्रेणीत टाकायचे हे स्पष्ट नाही आणि पुन्हा तुम्हाला प्रत्येक पीआरसह स्वतंत्रपणे हाताळावे लागेल. या समस्येचे निराकरण करण्यासाठी, आम्ही दुसरी क्रिया वापरू शकतो - लेबल सत्यापनकर्ता - ते पुल विनंतीवर टॅगची उपस्थिती तपासते. आवश्यक टॅग नसल्यास, चेक अयशस्वी होईल आणि आम्हाला आमच्या पुल विनंतीमध्ये याबद्दल एक संदेश दिसेल.

name: "Verify type labels"

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

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

आता कोणतीही पुल-विनंती टॅगपैकी एकाने चिन्हांकित करणे आवश्यक आहे: type:fix, type:features, type:documentation, type: tests, type:config.

पुल विनंत्यांचे स्वयं-भाष्य

आम्ही पुल विनंत्यांसह प्रभावी कार्य यासारख्या विषयावर स्पर्श केल्यामुळे, लेबलरसारख्या कृतीबद्दल बोलणे योग्य आहे, ते कोणत्या फायली बदलल्या आहेत यावर आधारित PR मध्ये टॅग ठेवते. उदाहरणार्थ, आम्ही निर्देशिकेत बदल असलेली कोणतीही पुल विनंती [build] म्हणून चिन्हांकित करू शकतो .github/workflow.

ते कनेक्ट करणे अगदी सोपे आहे:

name: "Auto-assign themes to PR"

on:
  - pull_request

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

आम्हाला प्रकल्प निर्देशिका आणि पुल विनंती विषयांमधील पत्रव्यवहाराचे वर्णन करणारी फाइल देखील आवश्यक आहे:

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

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

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

theme:documentation:
  - "docs/**"

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

आवश्यक लेबल्सची उपस्थिती तपासणार्‍या क्रियेसह पुल विनंत्यांमध्ये आपोआप लेबल ठेवणारी कृती जोडण्यात मी यशस्वी झालो नाही; मॅच-लेबल बॉटने जोडलेली लेबले पाहू इच्छित नाही. दोन्ही अवस्था एकत्र करणारी तुमची स्वतःची कृती लिहिणे सोपे वाटते. परंतु या फॉर्ममध्ये देखील ते वापरणे खूप सोयीचे आहे; पुल विनंती तयार करताना आपल्याला सूचीमधून लेबल निवडण्याची आवश्यकता आहे.

तैनात करण्याची वेळ आली आहे

मी GitHub क्रियांद्वारे (ssh द्वारे, scp द्वारे आणि docker-hub वापरून) अनेक उपयोजन पर्याय वापरून पाहिले आणि मी असे म्हणू शकतो की, तुमची पाइपलाइन कितीही वाकडी असली तरीही, तुम्हाला बायनरी सर्व्हरवर अपलोड करण्याचा मार्ग सापडेल. आहे

मला संपूर्ण पायाभूत सुविधा एकाच ठिकाणी ठेवण्याचा पर्याय आवडला, म्हणून गिटहब पॅकेजेसमध्ये कसे उपयोजित करायचे ते पाहूया (हे बायनरी सामग्री, एनपीएम, जार, डॉकरसाठी एक भांडार आहे).

डॉकर प्रतिमा तयार करण्यासाठी आणि गिटहब पॅकेजेसमध्ये प्रकाशित करण्यासाठी स्क्रिप्ट:

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 व्हेरिएबल रेपॉजिटरी आणि त्याच्या मालकाचे नाव (“मालक/रेपो-नाव”) संग्रहित करते. रेपॉजिटरीचे नाव वगळता या ओळीतून सर्वकाही कापण्यासाठी, आम्ही बॅश सिंटॅक्स वापरू: ${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 क्रियांचा वापर करून आमच्या ऍप्लिकेशनसाठी आरोग्य तपासणी कशी करायची याचा एक सोपा पर्याय पाहू. आमच्या बूट ऍप्लिकेशनमध्ये एक अॅक्ट्युएटर आहे, त्यामुळे आम्हाला त्याची स्थिती तपासण्यासाठी एपीआय लिहिण्याची गरज नाही; आळशींसाठी आम्ही आधीच सर्वकाही केले आहे. आपल्याला फक्त होस्ट खेचणे आवश्यक आहे: 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"

प्रथम, सर्व्हरने विनंतीला काय प्रतिसाद दिला ते आम्ही व्हेरिएबलमध्ये सेव्ह करतो, पुढील चरणात आम्ही स्थिती 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 }}

मागील पायरीवर क्रिया अयशस्वी झाल्यासच आम्ही टेलीग्रामवर पाठवतो. संदेश पाठवण्यासाठी आम्ही ऍपलबॉय/टेलिग्राम-ऍक्शन वापरतो; आपण दस्तऐवजात बॉट टोकन आणि चॅट आयडी कसा मिळवावा याबद्दल वाचू शकता: github.com/appleboy/telegram-action

Github वर रहस्ये लिहायला विसरू नका: सर्व्हरसाठी URL आणि टेलिग्राम बॉटसाठी टोकन.

बोनस ट्रॅक - आळशींसाठी JIRA

मी वचन दिले होते की आम्ही JIRA मध्ये परत येऊ आणि आम्ही परत आलो. मी शेकडो वेळा स्टँड-अपमध्ये अशी परिस्थिती पाहिली आहे जेव्हा डेव्हलपरने एक वैशिष्ट्य बनवले, शाखा विलीन केली, परंतु समस्या JIRA मध्ये ड्रॅग करण्यास विसरलो. अर्थात, हे सर्व एकाच ठिकाणी केले असल्यास, ते सोपे होईल, परंतु प्रत्यक्षात आपण IDE मध्ये कोड लिहितो, शाखांना बिटबकेट किंवा गिटहबमध्ये विलीन करतो आणि नंतर कार्ये जिरामध्ये ड्रॅग करतो, यासाठी आपल्याला नवीन विंडो उघडण्याची आवश्यकता आहे. , कधी कधी पुन्हा लॉग इन करा आणि इ. आपल्याला पुढे काय करायचे आहे हे जेव्हा आपल्याला पूर्णपणे आठवते, तेव्हा पुन्हा बोर्ड उघडण्यात काही अर्थ नाही. परिणामी, सकाळी स्टँडअपवर आपल्याला टास्क बोर्ड अद्यतनित करण्यात वेळ घालवावा लागेल.

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

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

बाधक

• YML, ठीक आहे, मला तो आवडत नाही. अशा प्रवाहासोबत काम करताना, माझ्याकडे सर्वात सामान्य कमिट मेसेज आहे “फिक्स yml फॉरमॅट”, नंतर तुम्ही कुठेतरी टॅब टाकायला विसरलात किंवा तुम्ही चुकीच्या ओळीवर लिहिता. सर्वसाधारणपणे, प्रोट्रेक्टर आणि शासक असलेल्या स्क्रीनसमोर बसणे हा सर्वात आनंददायी अनुभव नाही.
• डीबग, कमिटसह प्रवाह डीबग करणे, पुनर्बांधणी चालवणे आणि कन्सोलवर आऊटपुट करणे हे नेहमीच सोयीचे नसते, परंतु हे "तुम्ही ओव्हरडन केले" श्रेणीचे अधिक आहे; तुम्हाला सोयीस्कर IDEA सह काम करण्याची सवय आहे, जेव्हा तुम्ही काहीही डीबग करू शकता. .
• तुम्ही तुमची कृती डॉकरमध्ये गुंडाळल्यास त्यावर लिहू शकता, परंतु केवळ जावास्क्रिप्टला मूळ आधार आहे, अर्थात ही चवीची बाब आहे, परंतु मी js ऐवजी दुसरे काहीतरी पसंत करेन.

मी तुम्हाला आठवण करून देतो की सर्व स्क्रिप्टसह भांडार येथे आहे: github.com/antkorwin/github-actions

पुढच्या आठवड्यात मी सोबत परफॉर्म करणार आहे अहवाल Heisenbug 2020 Piter परिषदेत. चाचणी डेटा तयार करताना चुका कशा टाळाव्यात हे मी तुम्हाला सांगेन, तर Java अॅप्लिकेशन्समधील डेटा सेटसह कार्य करण्याचे माझे रहस्य देखील सांगेन!

स्त्रोत: www.habr.com