GitHub പ്രവർത്തനങ്ങളുള്ള നരകത്തിന്റെ സർക്കിളുകൾ (ഒരു ജാവ പ്രോജക്റ്റിനായി ഒരു CI/CD പൈപ്പ്ലൈൻ നിർമ്മിക്കുന്നു)

ജാവയിലെ നിർമ്മാണ പദ്ധതികൾക്കായി എനിക്ക് പലപ്പോഴും പൈപ്പ് ലൈൻ നിർമ്മിക്കേണ്ടി വരും. ചിലപ്പോൾ ഇത് ഓപ്പൺ സോഴ്‌സ് ആയിരിക്കും, ചിലപ്പോൾ അങ്ങനെയല്ല. Travis-CI, TeamCity എന്നിവയിൽ നിന്ന് GitHub പ്രവർത്തനങ്ങളിലേക്ക് എന്റെ ചില ശേഖരണങ്ങൾ മാറ്റാൻ ഞാൻ അടുത്തിടെ തീരുമാനിച്ചു, ഇതാണ് അതിൽ നിന്ന് പുറത്തുവന്നത്.

ഞങ്ങൾ എന്ത് ഓട്ടോമേറ്റ് ചെയ്യും?

ആദ്യം, നമുക്ക് ഓട്ടോമേറ്റ് ചെയ്യുന്ന ഒരു പ്രോജക്റ്റ് ആവശ്യമാണ്, നമുക്ക് സ്പ്രിംഗ് ബൂട്ട് / ജാവ 11 / മാവെനിൽ ഒരു ചെറിയ ആപ്ലിക്കേഷൻ ഉണ്ടാക്കാം. ഈ ലേഖനത്തിന്റെ ഉദ്ദേശ്യങ്ങൾക്കായി, ആപ്ലിക്കേഷൻ ലോജിക്കിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമില്ല; ആപ്ലിക്കേഷനെ ചുറ്റിപ്പറ്റിയുള്ള ഇൻഫ്രാസ്ട്രക്ചർ ഞങ്ങൾക്ക് പ്രധാനമാണ്, അതിനാൽ ഞങ്ങൾക്ക് ഒരു ലളിതമായ REST API കൺട്രോളർ മതിയാകും.

നിങ്ങൾക്ക് ഉറവിടങ്ങൾ ഇവിടെ കാണാൻ കഴിയും: github.com/antkorwin/github-actions പൈപ്പ് ലൈൻ നിർമ്മിക്കുന്നതിന്റെ എല്ലാ ഘട്ടങ്ങളും ഈ പ്രോജക്റ്റിനായുള്ള പുൾ അഭ്യർത്ഥനകളിൽ പ്രതിഫലിക്കുന്നു.

ജിറയും ആസൂത്രണവും

ഞങ്ങൾ സാധാരണയായി ഒരു ഇഷ്യൂ ട്രാക്കറായി JIRA ഉപയോഗിക്കുന്നുവെന്ന് പറയേണ്ടതാണ്, അതിനാൽ നമുക്ക് ഈ പ്രോജക്റ്റിനായി ഒരു പ്രത്യേക ബോർഡ് സൃഷ്‌ടിച്ച് ആദ്യത്തെ പ്രശ്‌നങ്ങൾ അവിടെ ചേർക്കാം:

കുറച്ച് കഴിഞ്ഞ് JIRA-യും GitHub-ഉം സംയോജിപ്പിച്ച് നൽകാൻ കഴിയുന്ന രസകരമായ കാര്യങ്ങളിലേക്ക് ഞങ്ങൾ മടങ്ങും.

പ്രോജക്റ്റിന്റെ അസംബ്ലി ഞങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നു

ഞങ്ങളുടെ ടെസ്റ്റ് പ്രോജക്റ്റ് നിർമ്മിച്ചിരിക്കുന്നത് മാവൻ വഴിയാണ്, അതിനാൽ ഇത് നിർമ്മിക്കുന്നത് വളരെ ലളിതമാണ്, ഞങ്ങൾക്ക് വേണ്ടത് 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/ push — മാസ്റ്ററിലേക്ക് ഒരു പുഷ് നടത്തുമ്പോഴും പുൾ അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കുമ്പോഴും ഈ വർക്ക്ഫ്ലോ സമാരംഭിക്കേണ്ടതുണ്ടെന്ന് സൂചിപ്പിക്കുന്നു.

ടാസ്ക്കുകളുടെ ഒരു വിവരണം താഴെ കൊടുക്കുന്നു (ജോലികൾ) കൂടാതെ നിർവ്വഹണ ഘട്ടങ്ങളും (ഘട്ടങ്ങൾ) ഓരോ ജോലിക്കും.

റൺ-ഓൺ - ഇവിടെ നമുക്ക് ടാർഗെറ്റ് ഒഎസ് തിരഞ്ഞെടുക്കാം, അതിശയകരമെന്നു പറയട്ടെ, നിങ്ങൾക്ക് 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 }}

ടെസ്റ്റുകൾ കവർ ചെയ്യാൻ, ജാക്കോകോ പ്ലഗിനുമായി ചേർന്ന് ഞാൻ codecov ഉപയോഗിക്കുന്നു. codecov-ന് അതിന്റേതായ പ്രവർത്തനമുണ്ട്, എന്നാൽ ഞങ്ങളുടെ പുൾ അഭ്യർത്ഥനയ്‌ക്കൊപ്പം പ്രവർത്തിക്കാൻ ഇതിന് ഒരു ടോക്കൺ ആവശ്യമാണ്:

${{ secrets.CODECOV_TOKEN }} — ഞങ്ങൾ ഈ നിർമ്മാണം ഒന്നിലധികം തവണ കാണും, രഹസ്യങ്ങൾ GitHub-ൽ രഹസ്യങ്ങൾ സംഭരിക്കുന്നതിനുള്ള ഒരു സംവിധാനമാണ്, നമുക്ക് അവിടെ പാസ്‌വേഡുകൾ / ടോക്കണുകൾ / ഹോസ്റ്റുകൾ / url കളും റിപ്പോസിറ്ററി കോഡ് ബേസിൽ ഉൾപ്പെടുത്താൻ പാടില്ലാത്ത മറ്റ് ഡാറ്റയും എഴുതാം.

GitHub-ലെ റിപ്പോസിറ്ററി ക്രമീകരണങ്ങളിൽ നിങ്ങൾക്ക് രഹസ്യങ്ങളിലേക്ക് ഒരു വേരിയബിൾ ചേർക്കാൻ കഴിയും:

എന്ന വിലാസത്തിൽ ടോക്കൺ ലഭിക്കും codecov.io GitHub വഴിയുള്ള അംഗീകാരത്തിന് ശേഷം, ഒരു പൊതു പ്രോജക്റ്റ് ചേർക്കുന്നതിന് നിങ്ങൾ ഇതുപോലുള്ള ഒരു ലിങ്ക് പിന്തുടരേണ്ടതുണ്ട്: 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 ജനറേറ്റ് ചെയ്യുന്ന ഒരു ബിൽറ്റ്-ഇൻ ടോക്കണാണ്, ഇതിന്റെ സഹായത്തോടെ സോണാർക്ലൗഡിന്[bot] Git-ലേക്ക് ലോഗിൻ ചെയ്യാൻ കഴിയും, അത് ഞങ്ങൾക്ക് പുൾ അഭ്യർത്ഥനകളിൽ സന്ദേശങ്ങൾ അയയ്ക്കും.

Dsonar.projectKey - സോണാറിലെ പ്രോജക്റ്റിന്റെ പേര്, നിങ്ങൾക്ക് അത് പ്രോജക്റ്റ് ക്രമീകരണങ്ങളിൽ കാണാൻ കഴിയും.

Dsonar.organization - GitHub-ൽ നിന്നുള്ള സ്ഥാപനത്തിന്റെ പേര്.

ഞങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന നടത്തുകയും അഭിപ്രായങ്ങളിൽ സോണാർക്ലൗഡ്[ബോട്ട്] വരുന്നതിനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു:

റിലീസ് മാനേജുമെന്റ്

ബിൽഡ് കോൺഫിഗർ ചെയ്‌തു, ടെസ്റ്റുകൾ റൺ ചെയ്‌തു, ഞങ്ങൾക്ക് ഒരു റിലീസ് ചെയ്യാം. 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-ൽ ടാഗുകൾ ഇടാൻ മറന്നാലോ? അപ്പോൾ ഏത് വിഭാഗത്തിലാണ് ഇത് ഉൾപ്പെടുത്തേണ്ടതെന്ന് വ്യക്തമല്ല, വീണ്ടും ഓരോ പിആറിലും വെവ്വേറെ നിങ്ങൾ ഇത് സ്വമേധയാ കൈകാര്യം ചെയ്യേണ്ടിവരും. ഈ പ്രശ്നം പരിഹരിക്കാൻ, ഞങ്ങൾക്ക് മറ്റൊരു പ്രവർത്തനം ഉപയോഗിക്കാം - ലേബൽ വെരിഫയർ - ഇത് പുൾ അഭ്യർത്ഥനയിലെ ടാഗുകളുടെ സാന്നിധ്യം പരിശോധിക്കുന്നു. ആവശ്യമായ ടാഗുകൾ ഇല്ലെങ്കിൽ, പരിശോധന പരാജയപ്പെടും, ഞങ്ങളുടെ പുൾ അഭ്യർത്ഥനയിൽ ഇതിനെക്കുറിച്ചുള്ള ഒരു സന്ദേശം ഞങ്ങൾ കാണും.

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 വഴിയും ഡോക്കർ-ഹബ് ഉപയോഗിച്ചും) ഞാൻ നിരവധി വിന്യാസ ഓപ്ഷനുകൾ പരീക്ഷിച്ചു, നിങ്ങളുടെ പൈപ്പ്‌ലൈൻ എത്ര വളഞ്ഞതാണെങ്കിലും, സെർവറിലേക്ക് ബൈനറി അപ്‌ലോഡ് ചെയ്യുന്നതിനുള്ള ഒരു വഴി നിങ്ങൾ കണ്ടെത്തുമെന്ന് എനിക്ക് പറയാൻ കഴിയും. ആണ്.

മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറും ഒരിടത്ത് സൂക്ഷിക്കുന്നതിനുള്ള ഓപ്ഷൻ എനിക്ക് ഇഷ്ടപ്പെട്ടു, അതിനാൽ GitHub പാക്കേജുകളിലേക്ക് എങ്ങനെ വിന്യസിക്കാമെന്ന് നോക്കാം (ഇത് ബൈനറി ഉള്ളടക്കം, npm, ജാർ, ഡോക്കർ എന്നിവയ്ക്കുള്ള ഒരു ശേഖരമാണ്).

ഒരു ഡോക്കർ ഇമേജ് നിർമ്മിക്കുന്നതിനും അത് 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 Packages Repository-ലേക്ക് പ്രസിദ്ധീകരിക്കുക:

docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"

ചിത്രത്തിന്റെ പതിപ്പ് സൂചിപ്പിക്കാൻ, ഞങ്ങൾ കമ്മിറ്റിന്റെ SHA ഹാഷിൽ നിന്നുള്ള ആദ്യ അക്കങ്ങൾ ഉപയോഗിക്കുന്നു - GITHUB_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

Curl വഴി സെർവർ നില നേരിട്ട് പരിശോധിക്കാം:

jobs:
  ping:
    runs-on: ubuntu-18.04
    steps:

      - name: curl actuator
        id: ping
        run: |
          echo "::set-output name=status::$(curl ${{secrets.SERVER_HOST}}/api/actuator/health)"

      - name: health check
        run: |
          if [[ ${{ steps.ping.outputs.status }} != *"UP"* ]]; then
            echo "health check is failed"
            exit 1
          fi
          echo "It's OK"

ആദ്യം, അഭ്യർത്ഥനയോട് സെർവർ പ്രതികരിച്ചത് ഞങ്ങൾ ഒരു വേരിയബിളിലേക്ക് സംരക്ഷിക്കുന്നു, അടുത്ത ഘട്ടത്തിൽ സ്റ്റാറ്റസ് യുപി ആണെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു, അങ്ങനെയല്ലെങ്കിൽ, ഒരു പിശക് ഉപയോഗിച്ച് ഞങ്ങൾ പുറത്തുകടക്കുന്നു. നിങ്ങളുടെ കൈകളാൽ ഒരു പ്രവർത്തനത്തെ "മറയ്ക്കാൻ" ആവശ്യമെങ്കിൽ, പിന്നെ പുറത്തുകടക്കുക 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

ഞങ്ങൾ ജിറയിലേക്ക് മടങ്ങുമെന്ന് ഞാൻ വാഗ്ദാനം ചെയ്തു, ഞങ്ങൾ മടങ്ങി. ഡവലപ്പർമാർ ഒരു ഫീച്ചർ ഉണ്ടാക്കിയപ്പോൾ, ഒരു ബ്രാഞ്ച് ലയിപ്പിച്ചപ്പോൾ സ്റ്റാൻഡ്-അപ്പുകളിൽ നൂറുകണക്കിന് തവണ ഞാൻ ഒരു സാഹചര്യം നിരീക്ഷിച്ചിട്ടുണ്ട്, പക്ഷേ പ്രശ്നം JIRA-യിലേക്ക് വലിച്ചിടാൻ മറന്നു. തീർച്ചയായും, ഇതെല്ലാം ഒരിടത്ത് ചെയ്താൽ, അത് എളുപ്പമായിരിക്കും, പക്ഷേ വാസ്തവത്തിൽ ഞങ്ങൾ IDE-യിൽ കോഡ് എഴുതുന്നു, ശാഖകൾ ബിറ്റ്ബക്കറ്റിലോ GitHub-ലോ ലയിപ്പിക്കുക, തുടർന്ന് ടാസ്ക്കുകൾ ജിറയിലേക്ക് വലിച്ചിടുക, ഇതിനായി ഞങ്ങൾ പുതിയ വിൻഡോകൾ തുറക്കേണ്ടതുണ്ട്. , ചിലപ്പോൾ വീണ്ടും ലോഗിൻ ചെയ്യുക തുടങ്ങിയവ. അടുത്തതായി എന്താണ് ചെയ്യേണ്ടതെന്ന് നിങ്ങൾ നന്നായി ഓർക്കുമ്പോൾ, ബോർഡ് വീണ്ടും തുറക്കുന്നതിൽ അർത്ഥമില്ല. തൽഫലമായി, രാവിലെ ഒരു സ്റ്റാൻഡപ്പിൽ നിങ്ങൾ ടാസ്‌ക് ബോർഡ് അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് സമയം ചെലവഴിക്കേണ്ടതുണ്ട്.

ഈ പതിവ് ടാസ്‌ക്കിൽ GitHub ഞങ്ങളെ സഹായിക്കും; തുടക്കക്കാർക്കായി, ഞങ്ങൾ ഒരു പുൾ അഭ്യർത്ഥന സമർപ്പിക്കുമ്പോൾ പ്രശ്നങ്ങൾ സ്വയമേവ code_review കോളത്തിലേക്ക് വലിച്ചിടാം. ബ്രാഞ്ച് നാമകരണ കൺവെൻഷൻ പിന്തുടരുക മാത്രമാണ് നിങ്ങൾ ചെയ്യേണ്ടത്:

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

ഉദാഹരണത്തിന്, പ്രോജക്റ്റ് കീ "GitHub പ്രവർത്തനങ്ങൾ" GA ആണെങ്കിൽ, പിന്നെ GA-8-jira-bot GA-8 ടാസ്ക് നടപ്പിലാക്കുന്നതിനുള്ള ഒരു ശാഖയായിരിക്കാം.

ജിറയുമായുള്ള സംയോജനം അറ്റ്ലാസിയനിൽ നിന്നുള്ള പ്രവർത്തനങ്ങളിലൂടെയാണ് പ്രവർത്തിക്കുന്നത്, അവ തികഞ്ഞതല്ല, അവയിൽ ചിലത് എനിക്ക് വേണ്ടി പ്രവർത്തിച്ചിട്ടില്ലെന്ന് ഞാൻ പറയണം. എന്നാൽ തീർച്ചയായും പ്രവർത്തിക്കുന്നവയും സജീവമായി ഉപയോഗിക്കുന്നവയും മാത്രമേ ഞങ്ങൾ ചർച്ചചെയ്യൂ.

ആദ്യം നിങ്ങൾ ആക്ഷൻ ഉപയോഗിച്ച് 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 ശേഖരണത്തിൽ നേരിട്ട് ഒരു ഫീച്ചർ അഭ്യർത്ഥന രചയിതാവിന് എങ്ങനെ പോസ്റ്റ് ചെയ്യാം എന്ന് മനസിലാക്കാൻ നിങ്ങൾക്ക് സോഴ്സ് കോഡ് നോക്കാവുന്നതാണ്.
• അസംബ്ലിക്കായി ടാർഗെറ്റ് പ്ലാറ്റ്ഫോം തിരഞ്ഞെടുക്കുന്നത്: Linux, mac OS, windows എന്നിവ വളരെ രസകരമായ ഒരു സവിശേഷതയാണ്.
• Github പാക്കേജുകൾ ഒരു മഹത്തായ കാര്യമാണ്, മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറും ഒരിടത്ത് സൂക്ഷിക്കുന്നത് സൗകര്യപ്രദമാണ്, നിങ്ങൾ വ്യത്യസ്ത വിൻഡോകളിലൂടെ സർഫ് ചെയ്യേണ്ടതില്ല, എല്ലാം ഒന്നോ രണ്ടോ മൗസ് ക്ലിക്കുകളുടെ പരിധിയിലാണ്, കൂടാതെ GitHub പ്രവർത്തനങ്ങളുമായി തികച്ചും സംയോജിപ്പിച്ചിരിക്കുന്നു. സൗജന്യ പതിപ്പിലെ ഡോക്കർ രജിസ്ട്രി പിന്തുണയും ഒരു നല്ല നേട്ടമാണ്.
• GitHub ബിൽഡ് ലോഗുകളിൽ രഹസ്യങ്ങൾ മറയ്ക്കുന്നു, അതിനാൽ പാസ്‌വേഡുകളും ടോക്കണുകളും സംഭരിക്കുന്നതിന് ഇത് ഉപയോഗിക്കുന്നത് അത്ര ഭയാനകമല്ല. എന്റെ എല്ലാ പരീക്ഷണങ്ങളിലും, കൺസോളിൽ രഹസ്യം അതിന്റെ ശുദ്ധമായ രൂപത്തിൽ കാണാൻ എനിക്ക് കഴിഞ്ഞില്ല.
• ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റുകൾക്ക് സൗജന്യം

പരിഗണന:

• YML, ശരി, എനിക്ക് അവനെ ഇഷ്ടമല്ല. അത്തരം ഒരു ഒഴുക്കിനൊപ്പം പ്രവർത്തിക്കുമ്പോൾ, എന്റെ ഏറ്റവും സാധാരണമായ കമ്മിറ്റ് സന്ദേശം "yml ഫോർമാറ്റ് ശരിയാക്കുക" ആണ്, തുടർന്ന് നിങ്ങൾ എവിടെയെങ്കിലും ഒരു ടാബ് ഇടാൻ മറക്കുകയോ തെറ്റായ വരിയിൽ എഴുതുകയോ ചെയ്യുന്നു. പൊതുവേ, ഒരു പ്രൊട്ടക്റ്ററും ഭരണാധികാരിയുമായി ഒരു സ്ക്രീനിന് മുന്നിൽ ഇരിക്കുന്നത് ഏറ്റവും സുഖകരമായ അനുഭവമല്ല.
• ഡീബഗ് ചെയ്യുക, കമ്മിറ്റുകൾ ഉപയോഗിച്ച് ഒഴുക്ക് ഡീബഗ് ചെയ്യുക, ഒരു റീബിൽഡ് പ്രവർത്തിപ്പിക്കുക, കൺസോളിലേക്ക് ഔട്ട്പുട്ട് ചെയ്യുക എന്നിവ എല്ലായ്‌പ്പോഴും സൗകര്യപ്രദമല്ല, എന്നാൽ ഇത് "നിങ്ങൾ അമിതമായി ചെയ്തു" എന്ന വിഭാഗത്തിൽ കൂടുതലാണ്; നിങ്ങൾക്ക് എന്തും ഡീബഗ് ചെയ്യാൻ കഴിയുമ്പോൾ സൗകര്യപ്രദമായ ഐഡിയ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ നിങ്ങൾ പതിവാണ്. .
• ഡോക്കറിൽ പൊതിഞ്ഞാൽ നിങ്ങളുടെ പ്രവർത്തനം നിങ്ങൾക്ക് എഴുതാൻ കഴിയും, എന്നാൽ ജാവാസ്ക്രിപ്റ്റ് മാത്രമേ പ്രാദേശികമായി പിന്തുണയ്ക്കുന്നുള്ളൂ, തീർച്ചയായും ഇത് അഭിരുചിയുടെ കാര്യമാണ്, പക്ഷേ js-ന് പകരം മറ്റെന്തെങ്കിലും ഞാൻ തിരഞ്ഞെടുക്കും.

എല്ലാ സ്ക്രിപ്റ്റുകളുമുള്ള ശേഖരം ഇവിടെ ഉണ്ടെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ: github.com/antkorwin/github-actions

അടുത്ത ആഴ്ച ഞാൻ കൂടെ പെർഫോം ചെയ്യും റിപ്പോർട്ട് Heisenbug 2020 Piter കോൺഫറൻസിൽ. ടെസ്റ്റ് ഡാറ്റ തയ്യാറാക്കുമ്പോൾ തെറ്റുകൾ എങ്ങനെ ഒഴിവാക്കാമെന്ന് മാത്രമല്ല, ജാവ ആപ്ലിക്കേഷനുകളിലെ ഡാറ്റാ സെറ്റുകളിൽ പ്രവർത്തിക്കുന്നതിന്റെ രഹസ്യങ്ങളും ഞാൻ നിങ്ങളോട് പറയും!

അവലംബം: www.habr.com