GitHub చర్యలతో నరకం యొక్క సర్కిల్‌లు (జావా ప్రాజెక్ట్ కోసం CI/CD పైప్‌లైన్‌ను నిర్మించడం)

నేను తరచుగా జావాలో ప్రాజెక్ట్‌లను నిర్మించడానికి పైప్‌లైన్‌ను నిర్మించాల్సి ఉంటుంది. కొన్నిసార్లు ఇది ఓపెన్ సోర్స్, కొన్నిసార్లు కాదు. నేను ఇటీవలే నా రిపోజిటరీలలో కొన్నింటిని ట్రావిస్-CI మరియు టీమ్‌సిటీ నుండి GitHub చర్యలకు తరలించాలని నిర్ణయించుకున్నాను మరియు ఇది దాని నుండి వచ్చింది.

మేము ఏమి ఆటోమేట్ చేస్తాము?

మొదట, మనకు ఆటోమేట్ చేసే ప్రాజెక్ట్ అవసరం, స్ప్రింగ్ బూట్ / జావా 11 / మావెన్‌లో చిన్న అప్లికేషన్ చేద్దాం. ఈ కథనం యొక్క ప్రయోజనాల కోసం, మేము అప్లికేషన్ లాజిక్‌పై అస్సలు ఆసక్తి చూపము; అప్లికేషన్ చుట్టూ ఉన్న మౌలిక సదుపాయాలు మాకు ముఖ్యమైనవి, కాబట్టి సాధారణ REST API కంట్రోలర్ మాకు సరిపోతుంది.

మీరు ఇక్కడ మూలాధారాలను చూడవచ్చు: github.com/antkorwin/github-actions పైప్‌లైన్ నిర్మాణం యొక్క అన్ని దశలు ఈ ప్రాజెక్ట్ కోసం పుల్ అభ్యర్థనలలో ప్రతిబింబిస్తాయి.

JIRA మరియు ప్రణాళిక

మేము సాధారణంగా JIRA ను ఇష్యూ ట్రాకర్‌గా ఉపయోగిస్తామని చెప్పడం విలువైనదే, కాబట్టి ఈ ప్రాజెక్ట్ కోసం ప్రత్యేక బోర్డ్‌ను క్రియేట్ చేద్దాం మరియు అక్కడ మొదటి సమస్యలను జోడిద్దాం:

కొద్దిసేపటి తర్వాత మేము JIRA మరియు GitHub కలయికలో అందించే ఆసక్తికరమైన విషయాలకు తిరిగి వస్తాము.

మేము ప్రాజెక్ట్ యొక్క అసెంబ్లీని ఆటోమేట్ చేస్తాము

మా టెస్ట్ ప్రాజెక్ట్ మావెన్ ద్వారా నిర్మించబడింది, కాబట్టి దీన్ని నిర్మించడం చాలా సులభం, మాకు కావలసిందల్లా mvn క్లీన్ ప్యాకేజీ.

Github చర్యలను ఉపయోగించి దీన్ని చేయడానికి, మేము రిపోజిటరీలో మా వర్క్‌ఫ్లోను వివరించే ఫైల్‌ను సృష్టించాలి, ఇది సాధారణ 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 — ఇది మా స్క్రిప్ట్ ప్రారంభించబడే ఈవెంట్ యొక్క వివరణ.

ఆన్: pull_request/push — మాస్టర్‌కు పుష్ చేయబడిన ప్రతిసారీ మరియు పుల్ అభ్యర్థనలు సృష్టించబడిన ప్రతిసారీ ఈ వర్క్‌ఫ్లో ప్రారంభించబడాలని సూచిస్తుంది.

కిందిది పనుల వివరణ (ఉద్యోగాలు) మరియు అమలు దశలు (దశలను) ప్రతి పనికి.

పరుగులు-ఆన్ - ఇక్కడ మేము లక్ష్య OSని ఎంచుకోవచ్చు, ఆశ్చర్యకరంగా, మీరు Mac OSని కూడా ఎంచుకోవచ్చు, కానీ ప్రైవేట్ రిపోజిటరీలలో ఇది చాలా ఖరీదైనది (Linuxతో పోలిస్తే).

ఉపయోగాలు ఇతర చర్యలను తిరిగి ఉపయోగించుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది, ఉదాహరణకు, మేము జావా 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 }}

పరీక్షలను కవర్ చేయడానికి, నేను జాకోకో ప్లగిన్‌తో కలిపి కోడ్‌కోవ్‌ని ఉపయోగిస్తాను. 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>

ఇప్పుడు కోడ్‌కోవ్ బాట్ మా ప్రతి పుల్ అభ్యర్థనలను నమోదు చేస్తుంది మరియు కవరేజ్ మార్పు గ్రాఫ్‌ను జోడిస్తుంది:

స్టాటిక్ ఎనలైజర్‌ని యాడ్ చేద్దాం

నా చాలా ఓపెన్ సోర్స్ ప్రాజెక్ట్‌లలో నేను స్టాటిక్ కోడ్ విశ్లేషణ కోసం సోనార్ క్లౌడ్‌ని ఉపయోగిస్తాను, ట్రావిస్-సికి కనెక్ట్ చేయడం చాలా సులభం. కాబట్టి 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.organization - GitHub నుండి సంస్థ పేరు.

మేము పుల్ అభ్యర్థన చేస్తాము మరియు వ్యాఖ్యలలో సోనార్క్లౌడ్[bot] వచ్చే వరకు వేచి ఉంటాము:

విడుదల నిర్వహణ

బిల్డ్ కాన్ఫిగర్ చేయబడింది, పరీక్షలు అమలు చేయబడ్డాయి మరియు మేము విడుదల చేయవచ్చు. GitHub చర్యలు విడుదల నిర్వహణను ఎలా సులభతరం చేస్తాయో చూద్దాం.

పనిలో, బిట్‌బకెట్‌లో కోడ్ బేస్ ఉన్న ప్రాజెక్ట్‌లు నా దగ్గర ఉన్నాయి (ప్రతిదీ ఆ కథలో “నేను పగటిపూట బిట్‌బకెట్‌కి వ్రాస్తాను, రాత్రికి GitHubకి కట్టుబడి ఉంటాను”). దురదృష్టవశాత్తూ, బిట్‌బకెట్‌లో అంతర్నిర్మిత విడుదల నిర్వహణ సాధనాలు లేవు. ఇది ఒక సమస్య, ఎందుకంటే ప్రతి విడుదలకు మీరు మానవీయంగా సంగమంలో ఒక పేజీని సృష్టించాలి మరియు విడుదలలో చేర్చబడిన అన్ని లక్షణాలను అక్కడ విసిరివేయాలి, మనస్సు యొక్క ప్యాలెస్‌ల ద్వారా శోధించండి, జిరాలోని పనులు, రిపోజిటరీలో కట్టుబడి ఉంటాయి. పొరపాటు చేయడానికి చాలా అవకాశాలు ఉన్నాయి, మీరు ఏదైనా మర్చిపోవచ్చు లేదా చివరిసారి ఇప్పటికే విడుదల చేసిన దాన్ని నమోదు చేయవచ్చు, కొన్నిసార్లు లాగండి అభ్యర్థనను ఏ విధంగా వర్గీకరించాలో స్పష్టంగా తెలియదు - ఇది ఫీచర్ లేదా బగ్ పరిష్కారమా లేదా పరీక్షలను సవరించడం లేదా ఏదో మౌలిక సదుపాయాలు.

GitHub చర్యలు మనకు ఎలా సహాయపడతాయి? గొప్ప చర్య ఉంది - విడుదల డ్రాఫ్టర్, ఇది పుల్ అభ్యర్థనల వర్గాలను సెటప్ చేయడానికి మరియు విడుదల గమనికల ఫైల్‌లో స్వయంచాలకంగా వాటిని సమూహపరచడానికి విడుదల గమనికల ఫైల్ టెంప్లేట్‌ను సెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది:

నివేదికను సెటప్ చేయడానికి ఉదాహరణ టెంప్లేట్ (.github/release-drafter.yml):

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

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

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

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

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

డ్రాఫ్ట్ విడుదలను రూపొందించడానికి స్క్రిప్ట్‌ను జోడించండి (.github/workflows/release-draft.yml):

name: "Create draft release"

on:
  push:
    branches:
      - master

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

ఇప్పటి నుండి అన్ని పుల్ అభ్యర్థనలు స్వయంచాలకంగా విడుదల గమనికలలో సేకరించబడతాయి - మేజిక్!

ఇక్కడ ప్రశ్న తలెత్తవచ్చు: డెవలపర్లు PRలో ట్యాగ్‌లను ఉంచడం మరచిపోతే? అప్పుడు ఏ కేటగిరీలో ఉంచాలో స్పష్టంగా తెలియదు మరియు మళ్లీ మీరు ప్రతి PRతో విడిగా మాన్యువల్‌గా వ్యవహరించాలి. ఈ సమస్యను పరిష్కరించడానికి, మేము మరొక చర్యను ఉపయోగించవచ్చు - లేబుల్ వెరిఫైయర్ - ఇది పుల్ అభ్యర్థనలో ట్యాగ్‌ల ఉనికిని తనిఖీ చేస్తుంది. అవసరమైన ట్యాగ్‌లు లేకుంటే, చెక్ విఫలమవుతుంది మరియు మా పుల్ అభ్యర్థనలో దీని గురించి సందేశాన్ని చూస్తాము.

name: "Verify type labels"

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

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

ఇప్పుడు ఏదైనా పుల్-రిక్వెస్ట్ తప్పనిసరిగా ట్యాగ్‌లలో ఒకదానితో గుర్తించబడాలి: రకం:పరిష్కారం, రకం:ఫీచర్‌లు, రకం:డాక్యుమెంటేషన్, రకం:పరీక్షలు, రకం:కాన్ఫిగర్.

పుల్ అభ్యర్థనల స్వీయ-ఉల్లేఖన

పుల్ రిక్వెస్ట్‌లతో ప్రభావవంతమైన పని వంటి అంశాన్ని మేము తాకినందున, లేబులర్ వంటి చర్య గురించి మాట్లాడటం విలువైనదే, ఇది ఏ ఫైల్‌లు మార్చబడిందో ఆధారంగా PRలో ట్యాగ్‌లను ఉంచుతుంది. ఉదాహరణకు, డైరెక్టరీకి మార్పులను కలిగి ఉన్న ఏదైనా పుల్ అభ్యర్థనను మనం [బిల్డ్]గా గుర్తించవచ్చు .github/workflow.

దీన్ని కనెక్ట్ చేయడం చాలా సులభం:

name: "Auto-assign themes to PR"

on:
  - pull_request

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

ప్రాజెక్ట్ డైరెక్టరీలు మరియు పుల్ రిక్వెస్ట్ టాపిక్‌ల మధ్య సుదూరతను వివరించే ఫైల్ కూడా మాకు అవసరం:

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

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

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

theme:documentation:
  - "docs/**"

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

అవసరమైన లేబుల్‌ల ఉనికిని తనిఖీ చేసే చర్యతో స్వయంచాలకంగా పుల్ రిక్వెస్ట్‌లలో లేబుల్‌లను ఉంచే చర్యను జత చేయడంలో నేను విజయవంతం కాలేదు; బాట్ జోడించిన లేబుల్‌లను మ్యాచ్-లేబుల్ చూడాలనుకోదు. రెండు దశలను కలిపి మీ స్వంత చర్యను వ్రాయడం సులభం అనిపిస్తుంది. కానీ ఈ రూపంలో కూడా ఇది ఉపయోగించడానికి చాలా సౌకర్యవంతంగా ఉంటుంది; పుల్ అభ్యర్థనను సృష్టించేటప్పుడు మీరు జాబితా నుండి లేబుల్‌ను ఎంచుకోవాలి.

ఇది మోహరించడానికి సమయం

నేను GitHub చర్యల ద్వారా (ssh ద్వారా, scp ద్వారా మరియు డాకర్-హబ్ ఉపయోగించి) అనేక విస్తరణ ఎంపికలను ప్రయత్నించాను మరియు మీ పైప్‌లైన్ ఎంత వంకరగా ఉన్నా, సర్వర్‌కు బైనరీని అప్‌లోడ్ చేయడానికి మీరు ఒక మార్గాన్ని కనుగొంటారని నేను చెప్పగలను. ఉంది.

నేను మొత్తం అవస్థాపనను ఒకే చోట ఉంచే ఎంపికను ఇష్టపడ్డాను, కాబట్టి GitHub ప్యాకేజీలకు ఎలా అమర్చాలో చూద్దాం (ఇది బైనరీ కంటెంట్, npm, jar, డాకర్ కోసం రిపోజిటరీ).

డాకర్ చిత్రాన్ని రూపొందించడానికి మరియు దానిని GitHub ప్యాకేజీలలో ప్రచురించడానికి స్క్రిప్ట్:

name: Deploy docker image

on:
  push:
    branches:
      - 'master'

jobs:

  build_docker_image:
    runs-on: ubuntu-18.04
    steps:

#     Build JAR:
      - uses: actions/checkout@v1
      - name: set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 1.11
      - name: Maven Package
        run: mvn -B clean compile package -DskipTests

#     Set global environment variables:
      - name: set global env
        id: global_env
        run: |
          echo "::set-output name=IMAGE_NAME::${GITHUB_REPOSITORY#*/}"
          echo "::set-output name=DOCKERHUB_IMAGE_NAME::docker.pkg.github.com/${GITHUB_REPOSITORY}/${GITHUB_REPOSITORY#*/}"

#     Build Docker image:
      - name: Build and tag image
        run: |
          docker build -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:latest" -t "${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}:${GITHUB_SHA::8}" .

      - name: Docker login
        run: docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}

#     Publish image to github package repository:
      - name: Publish image
        env:
          IMAGE_NAME: $GITHUB_REPOSITORY
        run: docker push "docker.pkg.github.com/$GITHUB_REPOSITORY/${{ steps.global_env.outputs.IMAGE_NAME }}"

మొదట, మేము మా అప్లికేషన్ యొక్క JAR ఫైల్‌ను రూపొందించాలి, దాని తర్వాత మేము GitHub డాకర్ రిజిస్ట్రీకి మరియు మా చిత్రం పేరుకు మార్గాన్ని గణిస్తాము. మేము ఇంకా చూడని కొన్ని ఉపాయాలు ఇక్కడ ఉన్నాయి:

• ఒక నిర్మాణం వంటిది: echo “::set-output name=NAME::VALUE” ప్రస్తుత దశలో వేరియబుల్ విలువను సెట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది, తద్వారా అది అన్ని ఇతర దశల్లో చదవబడుతుంది.
• మీరు ఈ దశ యొక్క ఐడెంటిఫైయర్ ద్వారా మునుపటి దశలో సెట్ చేయబడిన వేరియబుల్ విలువను పొందవచ్చు: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
• ప్రామాణిక GITHUB_REPOSITORY వేరియబుల్ రిపోజిటరీ మరియు దాని యజమాని (“యజమాని/రెపో-పేరు”) పేరును నిల్వ చేస్తుంది. ఈ లైన్ నుండి రిపోజిటరీ పేరు మినహా అన్నింటినీ కత్తిరించడానికి, మేము బాష్ సింటాక్స్‌ని ఉపయోగిస్తాము: ${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"

చిత్రం యొక్క సంస్కరణను సూచించడానికి, మేము కమిట్ - GITHUB_SHA యొక్క SHA హాష్ నుండి మొదటి అంకెలను ఉపయోగిస్తాము, మీరు మాస్టర్‌లో విలీనం చేసేటప్పుడు మాత్రమే కాకుండా, పుల్ రిక్వెస్ట్ క్రియేషన్ ప్రకారం కూడా అలాంటి నిర్మాణాలను చేస్తే, ఇక్కడ సూక్ష్మ నైపుణ్యాలు కూడా ఉన్నాయి. ఈవెంట్, అప్పుడు Git చరిత్రలో మనం చూసే హాష్‌తో SHA సరిపోలకపోవచ్చు, ఎందుకంటే PRలో డెడ్‌లాకింగ్ చర్యలను నివారించడానికి చర్యలు/చెక్‌అవుట్ చర్య దాని స్వంత ప్రత్యేకమైన హాష్‌ని చేస్తుంది.

ప్రతిదీ సరిగ్గా పని చేస్తే, రిపోజిటరీలో ప్యాకేజీల విభాగాన్ని (https://github.com/antkorwin/github-actions/packages) తెరవడం ద్వారా, మీరు కొత్త డాకర్ చిత్రాన్ని చూస్తారు:

అక్కడ మీరు డాకర్ చిత్రం యొక్క సంస్కరణల జాబితాను కూడా చూడవచ్చు.

ఈ రిజిస్ట్రీతో పనిచేయడానికి మా సర్వర్‌ను కాన్ఫిగర్ చేయడం మరియు సేవను పునఃప్రారంభించడం మాత్రమే మిగిలి ఉంది. నేను బహుశా systemd ద్వారా దీన్ని ఎలా చేయాలో మరొకసారి మాట్లాడతాను.

పర్యవేక్షణ

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

కర్ల్ ద్వారా సర్వర్ స్థితిని మాన్యువల్‌గా తనిఖీ చేద్దాం:

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

గితుబ్‌లోని రహస్యాలను వ్రాయడం మర్చిపోవద్దు: సర్వర్ కోసం URL మరియు టెలిగ్రామ్ బాట్ కోసం టోకెన్‌లు.

బోనస్ ట్రాక్ - సోమరితనం కోసం JIRA

మేము JIRAకి తిరిగి వస్తామని నేను వాగ్దానం చేసాను మరియు మేము తిరిగి వచ్చాము. డెవలపర్‌లు ఒక ఫీచర్‌ని రూపొందించినప్పుడు, బ్రాంచ్‌ను విలీనం చేసినప్పుడు స్టాండ్-అప్‌ల వద్ద నేను వందల సార్లు పరిస్థితిని గమనించాను, అయితే సమస్యను JIRAలోకి లాగడం మర్చిపోయాను. వాస్తవానికి, ఇవన్నీ ఒకే చోట జరిగితే, అది సులభం అవుతుంది, అయితే వాస్తవానికి మేము IDE లో కోడ్ వ్రాస్తాము, శాఖలను బిట్‌బకెట్ లేదా GitHub లోకి విలీనం చేస్తాము, ఆపై పనులను జిరాలోకి లాగండి, దీని కోసం మనం కొత్త విండోలను తెరవాలి. , కొన్నిసార్లు మళ్లీ లాగిన్ అవ్వండి మరియు మొదలైనవి. మీరు తదుపరి ఏమి చేయాలో మీరు ఖచ్చితంగా గుర్తుంచుకున్నప్పుడు, బోర్డుని మళ్లీ తెరవడంలో అర్థం లేదు. ఫలితంగా, ఉదయం స్టాండప్‌లో మీరు టాస్క్ బోర్డ్‌ను అప్‌డేట్ చేయడానికి సమయాన్ని వెచ్చించాలి.

ఈ రొటీన్ టాస్క్‌లో GitHub కూడా మాకు సహాయం చేస్తుంది; స్టార్టర్స్ కోసం, మేము పుల్ అభ్యర్థనను సమర్పించినప్పుడు మేము సమస్యలను స్వయంచాలకంగా code_review కాలమ్‌లోకి లాగవచ్చు. మీరు చేయాల్సిందల్లా బ్రాంచ్ నామకరణ సమావేశాన్ని అనుసరించడం:

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

ఉదాహరణకు, ప్రాజెక్ట్ కీ "GitHub చర్యలు" GA అయితే, అప్పుడు GA-8-jira-bot GA-8 విధిని అమలు చేయడానికి ఒక శాఖ కావచ్చు.

JIRAతో ఏకీకరణ అట్లాసియన్ నుండి చర్యల ద్వారా పనిచేస్తుంది, అవి పరిపూర్ణంగా లేవు, వాటిలో కొన్ని నాకు అస్సలు పని చేయలేదని నేను చెప్పాలి. కానీ మేము ఖచ్చితంగా పనిచేసే మరియు చురుకుగా ఉపయోగించే వాటిని మాత్రమే చర్చిస్తాము.

ముందుగా మీరు చర్యను ఉపయోగించి JIRAకి లాగిన్ చేయాలి: atlassian/gajira-login

jobs:
  build:
    runs-on: ubuntu-latest
    name: Jira Workflow
    steps:
      - name: Login
        uses: atlassian/gajira-login@master
        env:
          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
          JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

దీన్ని చేయడానికి, మీరు JIRAలో టోకెన్ పొందాలి, దీన్ని ఎలా చేయాలో ఇక్కడ వివరించబడింది: confluence.atlassian.com/cloud/api-tokens-938839638.html

మేము శాఖ పేరు నుండి టాస్క్ ఐడెంటిఫైయర్‌ని సంగ్రహిస్తాము:

  - name: Find Issue
    id: find_issue
    shell: bash
    run: |
      echo "::set-output name=ISSUE_ID::$(echo ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}')"
      echo brach name: $GITHUB_HEAD_REF
      echo extracted issue: ${GITHUB_HEAD_REF} | egrep -o 'GA-[0-9]{1,4}'

  - name: Check Issue
    shell: bash
    run: |
      if [[ "${{steps.find_issue.outputs.ISSUE_ID}}" == "" ]]; then
        echo "Please name your branch according to the JIRA issue: [project_key]-[task_number]-branch_name"
        exit 1
      fi
      echo succcessfully found JIRA issue: ${{steps.find_issue.outputs.ISSUE_ID}}

మీరు GitHub మార్కెట్‌ప్లేస్‌లో శోధిస్తే, మీరు ఈ పని కోసం ఒక చర్యను కనుగొనవచ్చు, కానీ నేను బ్రాంచ్ పేరును ఉపయోగించి grepని ఉపయోగించి అదే విషయాన్ని వ్రాయవలసి వచ్చింది, ఎందుకంటే 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 వర్క్‌ఫ్లో నుండి ఇతర ఈవెంట్‌లను లాగవచ్చు. సాధారణంగా, ఇది మీ ఊహ మరియు సాధారణ ప్రక్రియలను ఆటోమేట్ చేయాలనే కోరికపై ఆధారపడి ఉంటుంది.

కనుగొన్న

మీరు క్లాసిక్ DEVOPS రేఖాచిత్రాన్ని చూస్తే, మేము అన్ని దశలను కవర్ చేసాము, బహుశా ఆపరేట్ చేయడం తప్ప, మీరు ప్రయత్నిస్తే, మీరు హెల్ప్-డెస్క్ సిస్టమ్‌తో ఏకీకరణ కోసం మార్కెట్లో కొంత చర్యను కనుగొనవచ్చని నేను భావిస్తున్నాను, కాబట్టి పైప్‌లైన్ మారిందని మేము అనుకుంటాము. క్షుణ్ణంగా ఉండాలి మరియు దాని ఉపయోగం ఆధారంగా తీర్మానాలు చేయవచ్చు.

ప్రోస్:

• అన్ని సందర్భాలలో సిద్ధంగా ఉన్న చర్యలతో మార్కెట్‌ప్లేస్, ఇది చాలా బాగుంది. వాటిలో చాలా వరకు, మీరు సారూప్య సమస్యను ఎలా పరిష్కరించాలో అర్థం చేసుకోవడానికి సోర్స్ కోడ్‌ను కూడా చూడవచ్చు లేదా GitHub రిపోజిటరీలో నేరుగా రచయితకు ఫీచర్ అభ్యర్థనను పోస్ట్ చేయవచ్చు.
• అసెంబ్లీ కోసం టార్గెట్ ప్లాట్‌ఫారమ్‌ను ఎంచుకోవడం: Linux, mac os, windows చాలా ఆసక్తికరమైన ఫీచర్.
• Github ప్యాకేజీలు గొప్ప విషయం, మొత్తం మౌలిక సదుపాయాలను ఒకే చోట ఉంచడం సౌకర్యంగా ఉంటుంది, మీరు వేర్వేరు విండోల ద్వారా సర్ఫ్ చేయవలసిన అవసరం లేదు, ప్రతిదీ ఒకటి లేదా రెండు మౌస్ క్లిక్‌ల వ్యాసార్థంలో ఉంటుంది మరియు GitHub చర్యలతో సంపూర్ణంగా ఏకీకృతం చేయబడింది. ఉచిత సంస్కరణలో డాకర్ రిజిస్ట్రీ మద్దతు కూడా మంచి ప్రయోజనం.
• GitHub బిల్డ్ లాగ్‌లలో రహస్యాలను దాచిపెడుతుంది, కాబట్టి పాస్‌వర్డ్‌లు మరియు టోకెన్‌లను నిల్వ చేయడానికి దీన్ని ఉపయోగించడం అంత భయానకం కాదు. నా అన్ని ప్రయోగాల సమయంలో, కన్సోల్‌లో రహస్యాన్ని దాని స్వచ్ఛమైన రూపంలో చూడలేకపోయాను.
• ఓపెన్ సోర్స్ ప్రాజెక్ట్‌లకు ఉచితం

కాన్స్:

• YML, సరే, నేను అతనిని ఇష్టపడను. అటువంటి ప్రవాహంతో పని చేస్తున్నప్పుడు, నేను కలిగి ఉన్న అత్యంత సాధారణ కమిట్ మెసేజ్ "yml ఆకృతిని పరిష్కరించండి", అప్పుడు మీరు ఎక్కడో ఒక ట్యాబ్‌ను ఉంచడం మర్చిపోతారు లేదా మీరు దానిని తప్పు లైన్‌లో వ్రాస్తారు. సాధారణంగా, ప్రొట్రాక్టర్ మరియు రూలర్‌తో స్క్రీన్ ముందు కూర్చోవడం చాలా ఆహ్లాదకరమైన అనుభవం కాదు.
• డీబగ్, కమిట్‌లతో ఫ్లోను డీబగ్ చేయడం, రీబిల్డ్‌ని అమలు చేయడం మరియు కన్సోల్‌కి అవుట్‌పుట్ చేయడం ఎల్లప్పుడూ సౌకర్యవంతంగా ఉండదు, అయితే ఇది “మీరు ఓవర్‌డోన్ చేసారు” అనే వర్గానికి చెందినది; మీరు ఏదైనా డీబగ్ చేయగలిగినప్పుడు అనుకూలమైన IDEAతో పని చేయడం అలవాటు చేసుకున్నారు. .
• మీరు మీ చర్యను డాకర్‌లో చుట్టినట్లయితే మీరు దేనిపైనైనా వ్రాయవచ్చు, కానీ జావాస్క్రిప్ట్ మాత్రమే స్థానికంగా మద్దతు ఇస్తుంది, అయితే ఇది అభిరుచికి సంబంధించిన విషయం, కానీ నేను jsకి బదులుగా వేరొకదాన్ని ఇష్టపడతాను.

అన్ని స్క్రిప్ట్‌లతో కూడిన రిపోజిటరీ ఇక్కడ ఉందని నేను మీకు గుర్తు చేస్తున్నాను: github.com/antkorwin/github-actions

వచ్చే వారం నాతో కలిసి నటిస్తాను నివేదిక Heisenbug 2020 Piter సమావేశంలో. పరీక్ష డేటాను సిద్ధం చేసేటప్పుడు తప్పులను ఎలా నివారించాలో మాత్రమే కాకుండా, జావా అప్లికేషన్‌లలో డేటా సెట్‌లతో పని చేసే నా రహస్యాలను కూడా నేను మీకు చెప్తాను!

మూలం: www.habr.com