ჯოჯოხეთის წრეები GitHub მოქმედებებით (CI/CD მილსადენის აშენება Java პროექტისთვის)

მე ხშირად მიწევს მილსადენის აშენება Java-ზე სამშენებლო პროექტებისთვის. ზოგჯერ ის ღია წყაროა, ზოგჯერ არა. მე ცოტა ხნის წინ გადავწყვიტე გადამეტანა ჩემი ზოგიერთი საცავი Travis-CI-დან და TeamCity-დან GitHub Actions-ში და ეს არის ის, რაც გამოვიდა.

რას მოვახდენთ ავტომატიზირებას?

პირველ რიგში, ჩვენ გვჭირდება პროექტი, რომელსაც ჩვენ ავტომატიზირებთ, მოდით გავაკეთოთ პატარა აპლიკაცია Spring boot / Java 11 / Maven-ში. ამ სტატიის მიზნებისთვის ჩვენ საერთოდ არ დავინტერესდებით აპლიკაციის ლოგიკით, ჩვენთვის მნიშვნელოვანია აპლიკაციის ირგვლივ არსებული ინფრასტრუქტურა, ამიტომ მარტივი REST API კონტროლერი საკმარისი იქნება ჩვენთვის.

წყაროების ნახვა შეგიძლიათ აქ: github.com/antkorwin/github-actions მილსადენის მშენებლობის ყველა ეტაპი აისახება ამ პროექტის მოთხოვნებში.

JIRA და დაგეგმვა

ღირს იმის თქმა, რომ ჩვენ ჩვეულებრივ ვიყენებთ JIRA-ს, როგორც საკითხის ტრეკერს, ასე რომ, მოდით შევქმნათ ცალკე დაფა ამ პროექტისთვის და დავამატოთ პირველი საკითხები:

ცოტა მოგვიანებით ჩვენ დავუბრუნდებით იმას, თუ რა საინტერესო ნივთებს შეუძლიათ JIRA-მ და GitHub-მა შესთავაზონ კომბინაციაში.

ჩვენ ავტომატიზირებთ პროექტის აწყობას

ჩვენი სატესტო პროექტი აგებულია maven-ის მეშვეობით, ამიტომ მისი აშენება საკმაოდ მარტივია, რაც ჩვენ გვჭირდება არის mvn სუფთა პაკეტი.

Github Actions-ის გამოყენებით ამის გასაკეთებლად, ჩვენ უნდა შევქმნათ ფაილი საცავში, რომელიც აღწერს ჩვენს სამუშაო პროცესს, ეს შეიძლება გაკეთდეს ჩვეულებრივი yml ფაილით, ვერ ვიტყვი, რომ მომწონს "yml პროგრამირება", მაგრამ რა ვქნათ - ჩვენ ამას ვაკეთებთ .github/ directory workflow/ ფაილი 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 — ეს არის იმ ღონისძიების აღწერა, რომელზეც ჩვენი სკრიპტი დაიწყება.

on: pull_request/push — მიუთითებს, რომ ეს სამუშაო ნაკადი უნდა დაიწყოს ყოველ ჯერზე, როცა ოსტატთან ხდება ბიძგი და იქმნება pull-ის მოთხოვნები.

ქვემოთ მოცემულია დავალებების აღწერა (სამუშაო) და შესრულების ეტაპები (ნაბიჯები) თითოეული ამოცანისთვის.

გაშვებული - აქ ჩვენ შეგვიძლია შევარჩიოთ სამიზნე OS, გასაკვირია, რომ თქვენ შეგიძლიათ აირჩიოთ Mac OS, მაგრამ კერძო საცავებში ეს საკმაოდ ძვირია (ლინუქსის შედარებით).

გამოყენების საშუალებას გაძლევთ ხელახლა გამოიყენოთ სხვა მოქმედებები, მაგალითად, მოქმედებების/setup-java მოქმედების გამოყენებით ჩვენ ვაინსტალირებთ გარემოს Java 11-ისთვის.

საშუალებით ერთად ჩვენ შეგვიძლია განვსაზღვროთ ის პარამეტრები, რომლებითაც ვიწყებთ მოქმედებას, არსებითად ეს არის არგუმენტები, რომლებიც გადაეცემა მოქმედებას.

რჩება მხოლოდ პროექტის აშენება Maven-თან ერთად: run: mvn -B clean package დროშა -B ამბობს, რომ ჩვენ გვჭირდება არაინტერაქტიული რეჟიმი, რათა მავანმა უცებ არ მოინდომოს რაღაცის კითხვა

დიდი! ახლა, ყოველ ჯერზე, როდესაც თქვენ ვალდებულებას ასრულებთ მასტერს, იწყება პროექტის მშენებლობა.

ტესტის გაშვების ავტომატიზაცია

ასამბლეა კარგია, მაგრამ სინამდვილეში, პროექტი შეიძლება უსაფრთხოდ აწყობილი იყოს, მაგრამ არა იმუშაოს. ამიტომ, შემდეგი ნაბიჯი არის ტესტის გაშვების ავტომატიზაცია. გარდა ამისა, საკმაოდ მოსახერხებელია ტესტების ჩაბარების შედეგების დათვალიერება, როდესაც PR მიმოხილვას აკეთებთ - ზუსტად იცით, რომ ტესტები გადის და არავის დაავიწყდა თავისი ფილიალის გაშვება შერწყმის გაკეთებამდე.

ჩვენ ჩავატარებთ ტესტებს pull-ის მოთხოვნის შექმნისას და გავერთიანდებით მასტერში და ამავდროულად დავამატებთ ანგარიშის შექმნას კოდის დაფარვის შესახებ.

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-ს jacoco დანამატთან ერთად. codecov-ს აქვს საკუთარი მოქმედება, მაგრამ მას სჭირდება ჟეტონი, რომ იმუშაოს ჩვენს მოთხოვნით:

${{ secrets.CODECOV_TOKEN }} — ჩვენ ვნახავთ ამ კონსტრუქციას არაერთხელ, secrets არის GitHub-ში საიდუმლოების შენახვის მექანიზმი, ჩვენ შეგვიძლია დავწეროთ იქ პაროლები/ტოკენები/ჰოსტები/urls და სხვა მონაცემები, რომლებიც არ უნდა იყოს შეტანილი საცავის კოდის ბაზაში.

თქვენ შეგიძლიათ დაამატოთ ცვლადი საიდუმლოებებს GitHub-ის საცავის პარამეტრებში:

შეგიძლიათ მიიღოთ ჟეტონი მისამართზე codecov.io GitHub-ის ავტორიზაციის შემდეგ, საჯარო პროექტის დასამატებლად, უბრალოდ უნდა მიჰყვეთ მსგავს ბმულს: GitHub მომხმარებლის სახელი/[რეპოს სახელი]. ასევე შეიძლება დაემატოს კერძო საცავი; ამისათვის თქვენ უნდა მიანიჭოთ Codecov უფლებები აპლიკაციას Github-ში.

დაამატეთ jacoco მოდული POM ფაილში:

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

ახლა codecov ბოტი შეიყვანს ჩვენს თითოეულ მოთხოვნას და დაამატებს დაფარვის ცვლილების გრაფიკს:

მოდით დავამატოთ სტატიკური ანალიზატორი

ჩემი ღია კოდის პროექტების უმეტესობაში მე ვიყენებ სონარის ღრუბელს სტატიკური კოდის ანალიზისთვის, საკმაოდ მარტივია დაკავშირება travis-ci-სთან. ასე რომ, ლოგიკური ნაბიჯია GitHub Actions-ში მიგრაციისას იგივეს გაკეთება. სამოქმედო ბაზარი მაგარი რამეა, მაგრამ ამჯერად ცოტა დამამცირა, რადგან ჩვევის გამო ვიპოვე ის აქცია, რომელიც მჭირდებოდა და დავამატე სამუშაო პროცესზე. მაგრამ აღმოჩნდა, რომ სონარი არ უჭერს მხარს მავენზე ან გრადელზე პროექტების ანალიზზე მოქმედებით მუშაობას. რა თქმა უნდა, ეს დოკუმენტაციაში წერია, მაგრამ ვინ კითხულობს?!

ეს შეუძლებელია მოქმედების საშუალებით, ამიტომ ჩვენ ამას გავაკეთებთ 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-ში, რათა დაგვიტოვოს შეტყობინებები pull-ის მოთხოვნებში.

Dsonar.projectKey — პროექტის სახელწოდება სონარში, შეგიძლიათ იხილოთ პროექტის პარამეტრებში.

დსონარ.ორგანიზაცია - ორგანიზაციის სახელი GitHub-დან.

ჩვენ ვაკეთებთ მოთხოვნას და ველოდებით sonarcloud[bot]-ს კომენტარებში:

გამოშვების მენეჯმენტი

build კონფიგურირებულია, ტესტები ჩატარდა და ჩვენ შეგვიძლია გამოვაქვეყნოთ. მოდით შევხედოთ, თუ როგორ შეუძლია GitHub Actions-ს გათავისუფლების მართვა ბევრად უფრო ადვილი.

სამსახურში მაქვს პროექტები, რომელთა კოდის ბაზაც არის bitbucket-ში (ყველაფერი ისეა, როგორც ამ ამბავში: „დღით ბიტბაკეტს ვწერ, ღამით GitHub-ს ვწერ“). სამწუხაროდ, 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 }}

ამიერიდან მოზიდვის ყველა მოთხოვნა ავტომატურად შეგროვდება გამოშვების ნოტებში - მაგია!

აქ შეიძლება გაჩნდეს კითხვა: რა მოხდება, თუ დეველოპერებს დაავიწყდებათ ტეგების ჩასმა პიარში? მერე გაუგებარია რომელ კატეგორიაში ჩასვა და ისევ ხელით მოგიწევს საქმე, თითოეულ პიარზე ცალ-ცალკე. ამ პრობლემის გადასაჭრელად, ჩვენ შეგვიძლია გამოვიყენოთ სხვა მოქმედება - ეტიკეტების დამადასტურებელი - ის ამოწმებს ტეგების არსებობას pull მოთხოვნაზე. თუ არ არის საჭირო ტეგები, მაშინ შემოწმება ვერ მოხერხდება და ჩვენ ვნახავთ შეტყობინებას ამის შესახებ ჩვენს pull მოთხოვნაში.

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'

ახლა ნებისმიერი pull-მოთხოვნა უნდა იყოს მონიშნული ერთ-ერთი ტეგით: type:fix, type:features, type:documentation, type:tests, type:config.

გაყვანის მოთხოვნების ავტომატური ანოტაცია

ვინაიდან ჩვენ შევეხეთ ისეთ თემას, როგორიცაა ეფექტური მუშაობა pull-ის მოთხოვნებთან, ღირს ლაპარაკი ისეთ ქმედებაზე, როგორიცაა labeler, ის ათავსებს ტეგებს PR-ში, რომლის საფუძველზეც შეიცვალა ფაილები. მაგალითად, ჩვენ შეგვიძლია აღვნიშნოთ, როგორც [build] ნებისმიერი pull მოთხოვნა, რომელიც შეიცავს ცვლილებებს დირექტორიაში .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/**"

მე ვერ მოვახერხე იმ მოქმედების დაწყვილება, რომელიც ავტომატურად ათავსებს ლეიბლებს pull-ის მოთხოვნებში ქმედებით, რომელიც ამოწმებს საჭირო ლეიბლების არსებობას; match-label-ს არ სურს დაინახოს ბოტის მიერ დამატებული ლეიბლები. როგორც ჩანს, უფრო ადვილია საკუთარი მოქმედების დაწერა, რომელიც აერთიანებს ორივე ეტაპს. მაგრამ ამ ფორმითაც კი, მისი გამოყენება საკმაოდ მოსახერხებელია; თქვენ უნდა აირჩიოთ ეტიკეტი სიიდან, როდესაც შექმნით გაყვანის მოთხოვნებს.

განლაგების დროა

მე ვცადე განლაგების რამდენიმე ვარიანტი GitHub Actions-ის საშუალებით (ssh-ის მეშვეობით, scp-ის საშუალებით და docker-hub-ის გამოყენებით) და შემიძლია ვთქვა, რომ, სავარაუდოდ, იპოვით ორობითი სერვერზე ატვირთვის გზას, რაც არ უნდა დახრილი იყოს თქვენი მილსადენი. არის.

მომეწონა მთელი ინფრასტრუქტურის ერთ ადგილზე შენახვის ვარიანტი, ასე რომ, მოდით შევხედოთ როგორ განვათავსოთ GitHub პაკეტებში (ეს არის საცავი ბინარული შინაარსისთვის, npm, jar, docker).

სკრიპტი დოკერის სურათის შესაქმნელად და 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 ცვლადი ინახავს საცავის სახელს და მის მფლობელს („მფლობელი/რეპო-სახელი“). იმისათვის, რომ ამ ხაზიდან ყველაფერი ამოვაჭრათ, გარდა საცავის სახელისა, გამოვიყენებთ bash სინტაქსს: ${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 აქ ასევე არის ნიუანსები, თუ ასეთ ნაგებობებს აკეთებთ არა მხოლოდ მასტერში შერწყმისას, არამედ pull-მოთხოვნის შექმნის მიხედვითაც. მოვლენა, მაშინ SHA შეიძლება არ ემთხვეოდეს ჰეშს, რომელსაც ჩვენ ვხედავთ git ისტორიაში, რადგან ქმედებები/შემოწმების ქმედება ქმნის თავის უნიკალურ ჰეშს, რათა თავიდან აიცილოს ჩიხური ქმედებები PR-ში.

თუ ყველაფერი კარგად გამოვიდა, შემდეგ გახსნით პაკეტების განყოფილებას (https://github.com/antkorwin/github-actions/packages) საცავში, ნახავთ დოკერის ახალ სურათს:

აქ ასევე შეგიძლიათ იხილოთ დოკერის სურათის ვერსიების სია.

რჩება მხოლოდ ჩვენი სერვერის კონფიგურაცია ამ რეესტრთან მუშაობისთვის და სერვისის გადატვირთვა. მე ალბათ სხვა დროს ვისაუბრებ იმაზე, თუ როგორ გავაკეთო ეს systemd-ის მეშვეობით.

მონიტორინგი

მოდით შევხედოთ მარტივ ვარიანტს, თუ როგორ უნდა გავაკეთოთ ჯანმრთელობის შემოწმება ჩვენი აპლიკაციისთვის GitHub Actions-ის გამოყენებით. ჩვენს ჩატვირთვის აპლიკაციას აქვს აქტივატორი, ასე რომ, ჩვენ არ გვჭირდება 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"}

ჩვენ მხოლოდ გვჭირდება დავაწეროთ დავალება სერვერის შესამოწმებლად cron-ის გამოყენებით და თუ მოულოდნელად ის არ გვპასუხობს, მაშინ გამოგიგზავნით შეტყობინებას ტელეგრამის საშუალებით.

პირველი, მოდით გაერკვნენ, თუ როგორ უნდა გაუშვათ cron სამუშაო ნაკადი:

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"

პირველ რიგში, ჩვენ ვინახავთ ცვლადში იმას, რაც სერვერმა უპასუხა მოთხოვნას, შემდეგ ეტაპზე ვამოწმებთ, რომ სტატუსი არის 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-ს; შეგიძლიათ წაიკითხოთ, თუ როგორ უნდა მიიღოთ ბოტის ჟეტონი და ჩატის ID დოკუმენტაციაში: github.com/appleboy/telegram-action

არ დაგავიწყდეთ Github-ზე საიდუმლოების ჩაწერა: URL სერვერისთვის და ტოკენები ტელეგრამის ბოტისთვის.

ბონუს ტრეკი - JIRA ზარმაცებისთვის

დავპირდი, რომ JIRA-ში დავბრუნდებით და დავბრუნდით. ასობით ჯერ მინახავს სიტუაცია სტენდ-აპებზე, როდესაც დეველოპერებმა შექმნეს ფუნქცია, გააერთიანეს ფილიალი, მაგრამ დაავიწყდა საკითხის JIRA-ში გადატანა. რა თქმა უნდა, თუ ეს ყველაფერი ერთ ადგილზე გაკეთდა, უფრო ადვილი იქნებოდა, მაგრამ სინამდვილეში ჩვენ ვწერთ კოდს IDE-ში, ვაერთებთ ფილიალებს bitbucket-ში ან GitHub-ში და შემდეგ ჩავრთავთ ამოცანებს Jira-ში, ამისათვის საჭიროა ახალი ფანჯრების გახსნა. , ზოგჯერ ხელახლა შედით სისტემაში და ა.შ. როდესაც მშვენივრად გახსოვთ, რა უნდა გააკეთოთ შემდეგ, მაშინ დაფის ხელახლა გახსნას აზრი არ აქვს. შედეგად, დილით სადგამზე თქვენ უნდა დახარჯოთ დრო დავალების დაფის განახლებაზე.

GitHub ასევე დაგვეხმარება ამ რუტინულ ამოცანაში; დამწყებთათვის, ჩვენ შეგვიძლია ავტომატურად გადავიტანოთ საკითხები კოდი_მიმოხილვის სვეტში, როდესაც გამოვაგზავნით pull-ის მოთხოვნას. ყველაფერი რაც თქვენ უნდა გააკეთოთ არის ფილიალების დასახელების კონვენციის დაცვა:

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

მაგალითად, თუ პროექტის გასაღები "GitHub Actions" არის GA, მაშინ GA-8-jira-bot შეიძლება იყოს ფილიალი GA-8 დავალების განსახორციელებლად.

JIRA-სთან ინტეგრაცია Atlassian-ის მოქმედებებით მუშაობს, ისინი არ არიან სრულყოფილი, უნდა ითქვას, რომ ზოგიერთი მათგანი საერთოდ არ გამომივიდა. მაგრამ ჩვენ განვიხილავთ მხოლოდ მათ, ვინც ნამდვილად მუშაობს და აქტიურად გამოიყენება.

ჯერ უნდა შეხვიდეთ 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 Packages შესანიშნავი რამ არის, მოსახერხებელია მთელი ინფრასტრუქტურის ერთ ადგილას შენახვა, თქვენ არ გჭირდებათ სერფინგი სხვადასხვა ფანჯრებში, ყველაფერი მაუსის ერთი ან ორი დაწკაპუნების რადიუსშია და იდეალურად არის ინტეგრირებული GitHub Actions-თან. Docker რეესტრის მხარდაჭერა უფასო ვერსიაში ასევე კარგი უპირატესობაა.
• GitHub მალავს საიდუმლოებებს Build ჟურნალებში, ამიტომ მისი გამოყენება პაროლებისა და ნიშნების შესანახად არც ისე საშინელია. ყველა ჩემი ექსპერიმენტის დროს, მე ვერასოდეს შევძელი საიდუმლოს სუფთა სახით დანახვა კონსოლში.
• უფასო ღია კოდის პროექტებისთვის

Cons:

• YML, კარგი, მე ის არ მომწონს. ასეთ ნაკადთან მუშაობისას ყველაზე გავრცელებული commit მესიჯი, რაც მაქვს არის “fix yml format”, ხან სადმე ავიწყდება ჩანართის დადება, ხან არასწორ ხაზზე წერ. ზოგადად, ეკრანის წინ ჯდომა პროტრატორითა და სახაზავებით არ არის ყველაზე სასიამოვნო გამოცდილება.
• გამართვა, ნაკადის გამართვა შეთანხმებებით, აღდგენის გაშვება და კონსოლში გამოტანა ყოველთვის არ არის მოსახერხებელი, მაგრამ ეს უფრო მეტად არის „თქვენ გადააჭარბეთ“ კატეგორიას; თქვენ მიჩვეული ხართ მოსახერხებელი IDEA-სთან მუშაობას, როდესაც შეგიძლიათ რაიმეს გამართვა. .
• თქვენ შეგიძლიათ დაწეროთ თქვენი ქმედება ნებისმიერზე, თუ მას Docker-ში გადაიტანთ, მაგრამ მხოლოდ Javascript არის მხარდაჭერილი, რა თქმა უნდა, ეს გემოვნების საკითხია, მაგრამ მე სხვა რამეს მირჩევნია js-ის ნაცვლად.

შეგახსენებთ, რომ საცავი ყველა სკრიპტით არის აქ: github.com/antkorwin/github-actions

მომავალ კვირას ვითამაშებ ანგარიში Heisenbug 2020 Piter კონფერენციაზე. მე გეტყვით არა მხოლოდ, თუ როგორ ავიცილოთ თავიდან შეცდომები ტესტის მონაცემების მომზადებისას, არამედ გაგიზიარებთ Java აპლიკაციებში მონაცემთა ნაკრებებთან მუშაობის საიდუმლოებებს!

წყარო: www.habr.com