GitHub செயல்களுடன் நரகத்தின் வட்டங்கள் (ஜாவா திட்டத்திற்காக CI/CD பைப்லைனை உருவாக்குதல்)

ஜாவாவில் கட்டுமானத் திட்டங்களுக்கு நான் அடிக்கடி குழாய் அமைக்க வேண்டும். சில நேரங்களில் இது திறந்த மூலமாக இருக்கும், சில நேரங்களில் அது இல்லை. டிராவிஸ்-சிஐ மற்றும் டீம்சிட்டி ஆகியவற்றிலிருந்து கிட்ஹப் செயல்களுக்கு எனது சில களஞ்சியங்களை நகர்த்த முயற்சிக்க சமீபத்தில் முடிவு செய்தேன்.

நாம் எதை தானியக்கமாக்குவோம்?

முதலில், நமக்கு தானியங்குபடுத்தும் திட்டம் தேவை, ஸ்பிரிங் பூட் / ஜாவா 11 / மேவெனில் ஒரு சிறிய பயன்பாட்டை உருவாக்குவோம். இந்த கட்டுரையின் நோக்கங்களுக்காக, பயன்பாட்டு தர்க்கத்தில் நாங்கள் ஆர்வம் காட்ட மாட்டோம்; பயன்பாட்டைச் சுற்றியுள்ள உள்கட்டமைப்பு எங்களுக்கு முக்கியமானது, எனவே ஒரு எளிய REST API கட்டுப்படுத்தி எங்களுக்கு போதுமானதாக இருக்கும்.

ஆதாரங்களை நீங்கள் இங்கே பார்க்கலாம்: github.com/antkorwin/github-actions குழாய் அமைப்பதற்கான அனைத்து நிலைகளும் இந்த திட்டத்திற்கான இழுவை கோரிக்கைகளில் பிரதிபலிக்கின்றன.

ஜிரா மற்றும் திட்டமிடல்

நாங்கள் வழக்கமாக ஜிராவை ஒரு சிக்கல் கண்காணிப்பாளராகப் பயன்படுத்துகிறோம் என்று சொல்வது மதிப்புக்குரியது, எனவே இந்தத் திட்டத்திற்காக ஒரு தனி பலகையை உருவாக்கி, முதல் சிக்கல்களைச் சேர்ப்போம்:

சிறிது நேரம் கழித்து, ஜிரா மற்றும் கிட்ஹப் இணைந்து என்ன சுவாரஸ்யமான விஷயங்களை வழங்க முடியும் என்பதை நாங்கள் திரும்பப் பெறுவோம்.

திட்டத்தின் சட்டசபையை நாங்கள் தானியங்குபடுத்துகிறோம்

எங்கள் சோதனை திட்டம் மேவன் வழியாக கட்டப்பட்டது, எனவே அதை உருவாக்குவது மிகவும் எளிது, எங்களுக்கு தேவையானது mvn சுத்தமான தொகுப்பு மட்டுமே.

Github செயல்களைப் பயன்படுத்தி இதைச் செய்ய, எங்கள் பணிப்பாய்வுகளை விவரிக்கும் ஒரு கோப்பை நாம் களஞ்சியத்தில் உருவாக்க வேண்டும், இது வழக்கமான 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/mush — இந்த பணிப்பாய்வு ஒவ்வொரு முறையும் மாஸ்டருக்கு புஷ் செய்யப்படும்போதும், இழுக்கும் கோரிக்கைகள் உருவாக்கப்படும் போதும் தொடங்கப்பட வேண்டும் என்பதைக் குறிக்கிறது.

பின்வரும் பணிகளின் விளக்கம் (வேலைகள்) மற்றும் செயல்படுத்தும் படிகள் (படிகள்) ஒவ்வொரு பணிக்கும்.

இயங்கும் - இங்கே நாம் இலக்கு OS ஐத் தேர்ந்தெடுக்கலாம், ஆச்சரியப்படும் விதமாக, நீங்கள் Mac OS ஐக் கூட தேர்வு செய்யலாம், ஆனால் தனியார் களஞ்சியங்களில் இது மிகவும் விலை உயர்ந்தது (லினக்ஸுடன் ஒப்பிடும்போது).

பயன்கள் பிற செயல்களை மீண்டும் பயன்படுத்த உங்களை அனுமதிக்கிறது, எடுத்துக்காட்டாக, செயல்கள்/செட்டப்-ஜாவா செயலைப் பயன்படுத்தி, ஜாவா 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 இல் ரகசியங்களை சேமிப்பதற்கான ஒரு பொறிமுறையாகும், கடவுச்சொற்கள் / டோக்கன்கள் / ஹோஸ்ட்கள் / url கள் மற்றும் களஞ்சிய குறியீட்டு தளத்தில் சேர்க்கப்படாத பிற தரவுகளை எழுதலாம்.

GitHub இல் உள்ள களஞ்சிய அமைப்புகளில் நீங்கள் ரகசியங்களுக்கு ஒரு மாறியைச் சேர்க்கலாம்:

என்ற முகவரியில் டோக்கன் பெறலாம் codecov.io GitHub வழியாக அங்கீகாரம் பெற்ற பிறகு, ஒரு பொதுத் திட்டத்தைச் சேர்க்க, இது போன்ற இணைப்பைப் பின்தொடர வேண்டும்: GitHub பயனர் பெயர்/[ரெப்போ பெயர்]. ஒரு தனியார் களஞ்சியத்தையும் சேர்க்கலாம்; இதைச் செய்ய, நீங்கள் கிதுப்பில் உள்ள பயன்பாட்டிற்கு கோட்கோவ் உரிமைகளை வழங்க வேண்டும்.

POM கோப்பில் jacoco செருகுநிரலைச் சேர்க்கவும்:

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

இப்போது codecov bot எங்கள் இழுக்கும் கோரிக்கைகள் ஒவ்வொன்றையும் உள்ளிட்டு, கவரேஜ் மாற்ற வரைபடத்தைச் சேர்க்கும்:

நிலையான பகுப்பாய்வியைச் சேர்ப்போம்

எனது பெரும்பாலான ஓப்பன் சோர்ஸ் திட்டங்களில், நிலையான குறியீடு பகுப்பாய்விற்கு நான் சோனார் கிளவுட்டைப் பயன்படுத்துகிறேன், 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 உருவாக்கும் உள்ளமைக்கப்பட்ட டோக்கன் ஆகும், இதன் உதவியுடன் sonarcloud[bot] எங்களுக்கு செய்திகளை இழுக்கும் கோரிக்கைகளில் அனுப்ப Git இல் உள்நுழைய முடியும்.

Dsonar.projectKey - சொனாரில் உள்ள திட்டத்தின் பெயர், அதை நீங்கள் திட்ட அமைப்புகளில் பார்க்கலாம்.

Dsonar.அமைப்பு - GitHub இலிருந்து நிறுவனத்தின் பெயர்.

நாங்கள் இழுக்கும் கோரிக்கையை விடுத்து, கருத்துகளில் சோனார்க்ளவுட்[bot] வரும் வரை காத்திருக்கிறோம்:

வெளியீட்டு மேலாண்மை

உருவாக்கம் கட்டமைக்கப்பட்டுள்ளது, சோதனைகள் இயக்கப்பட்டன, மேலும் நாங்கள் வெளியிடலாம். கிட்ஹப் செயல்கள் வெளியீட்டு நிர்வாகத்தை எவ்வாறு எளிதாக்குகிறது என்பதைப் பார்ப்போம்.

வேலையில், பிட்பக்கெட்டில் குறியீட்டு அடிப்படையிலான திட்டங்கள் என்னிடம் உள்ளன (எல்லாமே அந்தக் கதையில் உள்ளதைப் போல "பகலில் பிட்பக்கெட்டுக்கு எழுதுகிறேன், இரவில் கிட்ஹப் செய்ய வேண்டும்"). துரதிருஷ்டவசமாக, bitbucket இல் உள்ளமைக்கப்பட்ட வெளியீட்டு மேலாண்மை கருவிகள் இல்லை. இது ஒரு பிரச்சனை, ஏனென்றால் ஒவ்வொரு வெளியீட்டிற்கும் நீங்கள் கைமுறையாக சங்கமத்தில் ஒரு பக்கத்தை உருவாக்கி, வெளியீட்டில் உள்ள அனைத்து அம்சங்களையும் அங்கே தூக்கி எறிந்து, மனதின் அரண்மனைகள், ஜிராவில் உள்ள பணிகள், களஞ்சியத்தில் செய்ய வேண்டும். தவறு செய்ய நிறைய வாய்ப்புகள் உள்ளன, நீங்கள் எதையாவது மறந்துவிடலாம் அல்லது ஏற்கனவே கடைசியாக வெளியிடப்பட்ட ஒன்றை உள்ளிடலாம், சில நேரங்களில் இழுக்கும் கோரிக்கையை என்ன வகைப்படுத்துவது என்பது தெளிவாகத் தெரியவில்லை - இது ஒரு அம்சமா அல்லது பிழைத் திருத்தமா அல்லது எடிட்டிங் சோதனைகள், அல்லது ஏதோ உள்கட்டமைப்பு .

GitHub செயல்கள் நமக்கு எப்படி உதவலாம்? ஒரு சிறந்த செயல் உள்ளது - வெளியீட்டு வரைவு, இது இழுக்கும் கோரிக்கைகளின் வகைகளை அமைக்க வெளியீட்டு குறிப்புகள் கோப்பு டெம்ப்ளேட்டை அமைக்க உங்களை அனுமதிக்கிறது மற்றும் வெளியீட்டு குறிப்புகள் கோப்பில் தானாகவே தொகுக்க:

அறிக்கையை அமைப்பதற்கான எடுத்துக்காட்டு டெம்ப்ளேட் (.github/release-drafter.yml):

name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
  - title: ' New Features'
    labels:
      - 'type:features'
# в эту категорию собираем все PR с меткой type:features

  - title: ' Bugs Fixes'
    labels:
      - 'type:fix'
# аналогично для метки type:fix и т.д.

  - title: ' Documentation'
    labels:
      - 'type:documentation'

  - title: ' Configuration'
    labels:
      - 'type:config'

change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
  ## Changes
  $CHANGES

வரைவு வெளியீட்டை உருவாக்க ஸ்கிரிப்டைச் சேர்க்கவும் (.github/workflows/release-draft.yml):

name: "Create draft release"

on:
  push:
    branches:
      - master

jobs:
  update_draft_release:
    runs-on: ubuntu-18.04
    steps:
      - uses: release-drafter/release-drafter@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

இனிமேல் இழுக்கும் கோரிக்கைகள் அனைத்தும் தானாகவே வெளியீட்டு குறிப்புகளில் சேகரிக்கப்படும் - மந்திரம்!

இங்கே கேள்வி எழலாம்: டெவலப்பர்கள் PR இல் குறிச்சொற்களை வைக்க மறந்துவிட்டால் என்ன செய்வது? அதை எந்த பிரிவில் வைப்பது என்பது தெளிவாகத் தெரியவில்லை, மீண்டும் ஒவ்வொரு PR உடன் தனித்தனியாக நீங்கள் அதை கைமுறையாக சமாளிக்க வேண்டும். இந்தச் சிக்கலைச் சரிசெய்ய, நாங்கள் மற்றொரு செயலைப் பயன்படுத்தலாம் - லேபிள் சரிபார்ப்பு - இது இழுக்கும் கோரிக்கையில் குறிச்சொற்கள் இருப்பதைச் சரிபார்க்கிறது. தேவையான குறிச்சொற்கள் இல்லை என்றால், காசோலை தோல்வியடையும், இது பற்றிய செய்தியை எங்கள் இழுத்தல் கோரிக்கையில் காண்போம்.

name: "Verify type labels"

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

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

இப்போது எந்த இழுக்கும் கோரிக்கையும் குறிச்சொற்களில் ஒன்றில் குறிக்கப்பட வேண்டும்: வகை:சரிசெய்தல், வகை:அம்சங்கள், வகை:ஆவணம், வகை:சோதனைகள், வகை:கட்டமைப்பு.

இழுக்கும் கோரிக்கைகளின் தானாக சிறுகுறிப்பு

இழுக்கும் கோரிக்கைகளுடன் பயனுள்ள வேலை போன்ற தலைப்பை நாங்கள் தொட்டதால், லேபிளர் போன்ற செயலைப் பற்றி பேசுவது மதிப்புக்குரியது, எந்த கோப்புகள் மாற்றப்பட்டுள்ளன என்பதன் அடிப்படையில் இது 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 ஐப் பயன்படுத்துவதன் மூலம்) பல வரிசைப்படுத்தல் விருப்பங்களை நான் முயற்சித்தேன், மேலும் உங்கள் பைப்லைன் எவ்வளவு வளைந்திருந்தாலும், பைனரியை சர்வரில் பதிவேற்றுவதற்கான வழியை நீங்கள் கண்டுபிடிப்பீர்கள் என்று என்னால் கூற முடியும். இருக்கிறது.

முழு உள்கட்டமைப்பையும் ஒரே இடத்தில் வைத்திருக்கும் விருப்பத்தை நான் விரும்பினேன், எனவே GitHub தொகுப்புகளை எவ்வாறு பயன்படுத்துவது என்பதைப் பார்ப்போம் (இது பைனரி உள்ளடக்கம், npm, jar, docker க்கான களஞ்சியம்).

டோக்கர் படத்தை உருவாக்கி அதை கிட்ஹப் தொகுப்புகளில் வெளியிடுவதற்கான ஸ்கிரிப்ட்:

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 மூலம் இதை எப்படி செய்வது என்பது பற்றி இன்னொரு முறை பேசுவேன்.

கண்காணிப்பு

கிட்ஹப் ஆக்ஷன்ஸைப் பயன்படுத்தி எங்களின் பயன்பாட்டிற்கான ஹெல்த் செக் செய்வது எப்படி என்பது குறித்த எளிய விருப்பத்தைப் பார்ப்போம். எங்கள் துவக்க பயன்பாட்டில் ஒரு ஆக்சுவேட்டர் உள்ளது, எனவே அதன் நிலையை சரிபார்க்க நாங்கள் 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

கர்ல் வழியாக சேவையக நிலையை கைமுறையாக சரிபார்க்கலாம்:

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 இல் உள்ள இரகசியங்களை எழுத மறக்காதீர்கள்: சேவையகத்திற்கான URL மற்றும் டெலிகிராம் போட்டிற்கான டோக்கன்கள்.

போனஸ் டிராக் - சோம்பேறிகளுக்கான ஜிரா

நாங்கள் ஜிராவுக்குத் திரும்புவோம் என்று நான் உறுதியளித்தேன், நாங்கள் திரும்பினோம். டெவலப்பர்கள் ஒரு அம்சத்தை உருவாக்கி, ஒரு கிளையை ஒன்றிணைத்தபோது, ​​ஸ்டாண்ட்-அப்களில் ஒரு சூழ்நிலையை நூற்றுக்கணக்கான முறை நான் கவனித்தேன், ஆனால் சிக்கலை JIRA க்குள் இழுக்க மறந்துவிட்டேன். நிச்சயமாக, இவை அனைத்தும் ஒரே இடத்தில் செய்யப்பட்டால், அது எளிதாக இருக்கும், ஆனால் உண்மையில் நாங்கள் ஐடிஇயில் குறியீட்டை எழுதுகிறோம், கிளைகளை பிட்பக்கெட் அல்லது கிட்ஹப்பில் இணைக்கிறோம், பின்னர் பணிகளை ஜிராவில் இழுக்கிறோம், இதற்காக நாம் புதிய சாளரங்களைத் திறக்க வேண்டும். , சில நேரங்களில் மீண்டும் உள்நுழைதல் மற்றும் பல. அடுத்து நீங்கள் என்ன செய்ய வேண்டும் என்பதை நீங்கள் சரியாக நினைவில் வைத்துக் கொண்டால், பலகையை மீண்டும் திறப்பதில் எந்த அர்த்தமும் இல்லை. இதன் விளைவாக, காலையில் ஒரு ஸ்டாண்டப்பில் நீங்கள் பணிப் பலகையைப் புதுப்பிக்க நேரத்தை செலவிட வேண்டும்.

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 ஐப் பயன்படுத்தி அதையே எழுத வேண்டியிருந்தது, ஏனெனில் 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 வடிவமைப்பை சரிசெய்யவும்", சில நேரங்களில் நீங்கள் எங்காவது ஒரு தாவலை வைக்க மறந்துவிடுவீர்கள், சில நேரங்களில் தவறான வரியில் எழுதுகிறீர்கள். பொதுவாக, ப்ரோட்ராக்டர் மற்றும் ரூலருடன் திரையின் முன் அமர்ந்திருப்பது மிகவும் இனிமையான அனுபவம் அல்ல.
• டீபக், கமிட்கள் மூலம் ஃப்ளோவை பிழைத்திருத்துதல், மறுகட்டமைப்பை இயக்குதல் மற்றும் கன்சோலுக்கு அவுட்புட் செய்வது எப்போதும் வசதியாக இருக்காது, ஆனால் இது "நீங்கள் அதிகமாக செய்துவிட்டீர்கள்" என்ற வகையைச் சேர்ந்தது; நீங்கள் எதையும் பிழைத்திருத்தம் செய்யும்போது வசதியான IDEA உடன் பணியாற்றப் பழகிவிட்டீர்கள். .
• உங்கள் செயலை டோக்கரில் மடித்தால் எதையும் எழுதலாம், ஆனால் ஜாவாஸ்கிரிப்ட் மட்டுமே பூர்வீகமாக ஆதரிக்கப்படும், நிச்சயமாக இது ரசனைக்குரிய விஷயம், ஆனால் js க்கு பதிலாக வேறு ஏதாவது ஒன்றை நான் விரும்புகிறேன்.

அனைத்து ஸ்கிரிப்ட்களையும் கொண்ட களஞ்சியம் இங்கே உள்ளது என்பதை உங்களுக்கு நினைவூட்டுகிறேன்: github.com/antkorwin/github-actions

அடுத்த வாரம் நான் உடன் நடிக்கிறேன் அறிக்கை Heisenbug 2020 Piter மாநாட்டில். சோதனைத் தரவைத் தயாரிக்கும்போது தவறுகளைத் தவிர்ப்பது மட்டுமல்லாமல், ஜாவா பயன்பாடுகளில் தரவுத் தொகுப்புகளுடன் பணிபுரியும் எனது ரகசியங்களையும் பகிர்ந்து கொள்கிறேன்!

ஆதாரம்: www.habr.com