Mən tez-tez Java-da layihələr qurmaq üçün boru kəməri çəkməli oluram. Bəzən açıq mənbə olur, bəzən isə yox. Bu yaxınlarda mən bəzi anbarlarımı Travis-CI və TeamCity-dən GitHub Actions-a köçürməyə cəhd etmək qərarına gəldim və bunun nəticəsi budur.
Nəyi avtomatlaşdıracağıq?
Əvvəlcə avtomatlaşdıracağımız bir layihə lazımdır, Spring boot / Java 11 / Maven-də kiçik bir tətbiq edək. Bu məqalənin məqsədləri üçün biz tətbiq məntiqi ilə heç maraqlanmayacağıq; proqramın ətrafındakı infrastruktur bizim üçün vacibdir, ona görə də sadə REST API nəzarətçisi bizə kifayət edəcəkdir.
Mənbələrə buradan baxa bilərsiniz: Boru kəmərinin tikintisinin bütün mərhələləri bu layihə üçün çəkiliş sorğularında öz əksini tapmışdır.
JIRA və planlaşdırma
Demək lazımdır ki, biz adətən JIRA-dan problem izləyicisi kimi istifadə edirik, ona görə də gəlin bu layihə üçün ayrıca lövhə yaradaq və ilk məsələləri oraya əlavə edək:
Bir az sonra biz JIRA və GitHub-un birlikdə təklif edə biləcəyi maraqlı şeylərə qayıdacağıq.
Layihənin yığılmasını avtomatlaşdırırıq
Test layihəmiz maven vasitəsilə qurulub, ona görə də onu qurmaq olduqca sadədir, bizə lazım olan tək şey mvn təmiz paketidir.
Bunu Github Actions-dan istifadə etməklə etmək üçün biz depoda iş prosesimizi təsvir edən fayl yaratmalıyıq, bunu adi yml faylı ilə etmək olar, deyə bilmərəm ki, “yml proqramlaşdırmanı” bəyənirəm, amma nə edə bilərik - biz bunu .github/ directory workflow/ build.yml faylında edirik, burada master filialı qurarkən hərəkətləri təsvir edəcəyik:
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 — bu, ssenarimizin işə salınacağı tədbirin təsviridir.
açıq: pull_request/push — masterə hər dəfə təkan verildikdə və çəkmə sorğuları yaradılanda bu iş axınının işə salınmalı olduğunu göstərir.
Aşağıda tapşırıqların təsviri verilmişdir (iş) və icra mərhələləri (addımlar) hər tapşırıq üçün.
qaçır - burada hədəf ƏS-ni seçə bilərik, təəccüblüdür ki, hətta Mac OS-ni də seçə bilərsiniz, lakin şəxsi depolarda bu olduqca bahadır (Linux ilə müqayisədə).
istifadə digər hərəkətləri təkrar istifadə etməyə imkan verir, məsələn, Java 11 üçün mühiti quraşdırdığımız actions/setup-java əməliyyatından istifadə etməklə.
Vasitəsilə ilə biz hərəkətə başladığımız parametrləri təyin edə bilərik, əslində bunlar hərəkətə ötürüləcək arqumentlərdir.
Maven ilə layihənin qurulmasını idarə etmək qalır: run: mvn -B clean package bayraq -B deyir ki, bizə qeyri-interaktiv rejim lazımdır ki, maven birdən bizdən nəsə soruşmaq istəməsin.
Əla! İndi hər dəfə ustaya öhdəlik götürəndə layihənin qurulması başlayır.
Testlərin avtomatlaşdırılması
Montaj yaxşıdır, amma əslində bir layihə təhlükəsiz şəkildə yığıla bilər, amma işləmir. Buna görə də növbəti addım sınaqların avtomatlaşdırılmasıdır. Bundan əlavə, PR nəzərdən keçirərkən testlərdən keçməyin nəticələrinə baxmaq olduqca rahatdır - siz əminsiniz ki, testlər keçib və heç kim birləşmədən əvvəl filialını işə salmağı unutmayıb.
Biz çəkmə sorğusu yaratarkən testlər aparacağıq və master-a birləşdirəcəyik və eyni zamanda kod əhatə dairəsi haqqında hesabatın yaradılmasını əlavə edəcəyik.
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 }}
Testləri əhatə etmək üçün jacoco plagini ilə birlikdə codecov-dan istifadə edirəm. codecovun öz hərəkəti var, lakin bizim çəkmə sorğumuzla işləmək üçün ona işarə lazımdır:
${{ secrets.CODECOV_TOKEN }} — biz bu konstruksiyanı bir dəfədən çox görəcəyik, sirlər GitHub-da sirlərin saxlanması mexanizmidir, biz ora parollar/tokenlər/hostlar/urllər və depo kod bazasına daxil edilməməli olan digər məlumatları yaza bilərik.
GitHub-da depo parametrlərində sirrlərə dəyişən əlavə edə bilərsiniz:
Siz token əldə edə bilərsiniz GitHub vasitəsilə avtorizasiyadan sonra ictimai layihə əlavə etmək üçün sadəcə olaraq bu kimi bir keçidi izləməlisiniz: /[repo adı]. Şəxsi repozitoriya da əlavə edilə bilər; bunun üçün Github-da tətbiqə codecov hüquqlarını verməlisiniz.
POM faylına jacoco plaginini əlavə edin:
<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>
İndi codecov botu çəkmə sorğularımızın hər birinə daxil olacaq və əhatə dairəsinin dəyişmə qrafiki əlavə edəcək:
Statik analizator əlavə edək
Açıq mənbə layihələrimin əksəriyyətində statik kod analizi üçün sonar buludundan istifadə edirəm, travis-ci-yə qoşulmaq olduqca asandır. Beləliklə, eyni şeyi etmək üçün GitHub Actions-a köçərkən məntiqli bir addımdır. Fəaliyyət bazarı gözəl bir şeydir, amma bu dəfə məni bir az ruhdan saldı, çünki vərdişimdən lazım olan hərəkəti tapdım və onu iş axınına əlavə etdim. Lakin məlum oldu ki, sonar maven və ya gradle-də layihələri təhlil etmək üçün fəaliyyətlə işləməyi dəstəkləmir. Təbii ki, bu sənədləşmədə yazılıb, amma kim oxuyur?!
Fəaliyyət vasitəsilə bu mümkün deyil, ona görə də bunu mvn plagini vasitəsilə edəcəyik:
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 - ünvanından əldə edə bilərsiniz və bunu gizli şəkildə qeydiyyatdan keçirməlisiniz. GITHUB_TOKEN - bu, GitHub-un yaratdığı daxili tokendir, onun köməyi ilə sonarcloud[bot] bizə pull sorğularında mesajlar buraxmaq üçün Git-ə daxil ola biləcək.
Dsonar.projectKey — sonardakı layihənin adı, onu layihə parametrlərində görə bilərsiniz.
Dsonar.organization — GitHub-dan təşkilatın adı.
Biz sorğu göndəririk və sonarcloud[bot]-un şərhlərdə gəlməsini gözləyirik:
Release idarə
Quraşdırma konfiqurasiya edildi, sınaqlar keçirildi və biz buraxılış edə bilərik. GitHub Actions-ın buraxılış idarəçiliyini necə asanlaşdıra biləcəyinə baxaq.
İşdə kod bazası bitbuketdə olan layihələrim var (hər şey o hekayədəki kimidir “Gündüzlər bitbuketə yazıram, gecələr GitHub-a bağlanıram”). Təəssüf ki, bitbucket-də daxili buraxılış idarəetmə vasitələri yoxdur. Bu bir problemdir, çünki hər buraxılış üçün əl ilə birləşməli bir səhifə yaratmalı və buraxılışa daxil olan bütün xüsusiyyətləri ora atmalı, ağıl saraylarını, jiradakı tapşırıqları, depoda öhdəliyi axtarmalısan. Səhv etmək üçün bir çox şans var, nəyisə unuda və ya sonuncu dəfə buraxılmış bir şeyi daxil edə bilərsiniz, bəzən çəkmə sorğusunu nə kimi təsnif etmək aydın deyil - bu, bir xüsusiyyətdir, yoxsa səhvlərin düzəldilməsidir, yoxsa redaktə testləridir, yoxsa infrastruktur bir şey.
GitHub hərəkətləri bizə necə kömək edə bilər? Mükəmməl bir fəaliyyət var - buraxılış tərtibçisi, o, çəkmə sorğularının kateqoriyalarını qurmaq və onları buraxılış qeydləri faylında avtomatik qruplaşdırmaq üçün buraxılış qeydləri faylı şablonunu təyin etməyə imkan verir:
Hesabatın yaradılması üçün nümunə şablon (.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
Qaralama buraxılış yaratmaq üçün skript əlavə edin (.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 }}
Bundan sonra bütün çəkmə sorğuları avtomatik olaraq buraxılış qeydlərində toplanacaq - sehrli!
Burada sual yarana bilər: əgər tərtibatçılar PR-a etiketlər qoymağı unudurlarsa necə? Onda onu hansı kateqoriyaya salmaq bəlli deyil və yenə də hər PR ilə ayrı-ayrılıqda əl ilə məşğul olmalı olacaqsınız. Bu problemi həll etmək üçün başqa bir hərəkətdən istifadə edə bilərik - etiket yoxlayıcısı - o, çəkmə sorğusunda etiketlərin olub-olmadığını yoxlayır. Tələb olunan etiketlər yoxdursa, yoxlama uğursuz olacaq və biz çəkmə sorğumuzda bu barədə bir mesaj görəcəyik.
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'
İndi istənilən çəkmə sorğusu aşağıdakı teqlərdən biri ilə qeyd edilməlidir: type:fix, type:features, type:sənədləşdirmə, type:tests, type:config.
Çəkmə sorğularının avtomatik annotasiyası
Çəkmə istəkləri ilə effektiv iş kimi bir mövzuya toxunduğumuz üçün etiketləyici kimi bir hərəkət haqqında danışmağa dəyər, hansı faylların dəyişdirilməsinə əsaslanaraq PR-a etiketlər qoyur. Məsələn, kataloqda dəyişiklikləri ehtiva edən istənilən çəkmə sorğusunu [qurmaq] kimi qeyd edə bilərik .github/workflow.
Onu bağlamaq olduqca sadədir:
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 }}
Bizə həmçinin layihə qovluqları və çəkmə sorğusu mövzuları arasında yazışmaları təsvir edən bir fayl lazımdır:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Çəkmə sorğularında etiketləri avtomatik yerləşdirən əməliyyatı tələb olunan etiketlərin olub-olmadığını yoxlayan əməliyyatla birləşdirə bilmədim; uyğunluq etiketi bot tərəfindən əlavə edilmiş etiketləri görmək istəmir. Hər iki mərhələni birləşdirən öz fəaliyyətinizi yazmaq daha asan görünür. Ancaq hətta bu formada istifadə etmək olduqca rahatdır, çəkmə sorğusu yaratarkən siyahıdan bir etiket seçməlisiniz.
Yerləşdirmə vaxtıdır
Mən GitHub Actions vasitəsilə (ssh vasitəsilə, scp vasitəsilə və docker-hub istifadə edərək) bir neçə yerləşdirmə variantını sınadım və deyə bilərəm ki, boru kəmərinizin nə qədər əyri olmasından asılı olmayaraq, ikili faylı serverə yükləməyin bir yolunu tapacaqsınız. edir.
Bütün infrastrukturu bir yerdə saxlamaq seçimini bəyəndim, ona görə də gəlin GitHub Paketlərinə necə yerləşdirməyə baxaq (bu, ikili məzmun, npm, jar, docker üçün depodur).
Docker şəklini yaratmaq və onu GitHub Paketlərində dərc etmək üçün skript:
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 }}"
Əvvəlcə tətbiqimizin JAR faylını qurmalıyıq, bundan sonra GitHub docker reyestrinə gedən yolu və şəklimizin adını hesablayırıq. Burada hələ rast gəlmədiyimiz bir neçə fənd var:
- konstruksiya kimi: echo “::set-output name=NAME::VALUE” cari addımda dəyişənin dəyərini təyin etməyə imkan verir ki, o, bütün digər addımlarda oxuna bilsin.
- bu addımın identifikatoru vasitəsilə əvvəlki addımda müəyyən edilmiş dəyişənin dəyərini əldə edə bilərsiniz: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standart GITHUB_REPOSITORY dəyişəni repozitoriyanın adını və onun sahibini (“sahibi/repo adı”) saxlayır. Bu sətirdən deponun adından başqa hər şeyi kəsmək üçün bash sintaksisindən istifadə edəcəyik: ${GITHUB_REPOSITORY#*/}
Sonra docker şəklini qurmalıyıq:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Qeydiyyata daxil olun:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Və şəkli GitHub Paketləri Repozitoriyasında dərc edin:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Şəklin versiyasını göstərmək üçün biz öhdəliyin SHA hashından ilk rəqəmlərdən istifadə edirik - GITHUB_SHA burada da nüanslar var, əgər siz bu cür quruluşları yalnız master-a birləşdirərkən deyil, həm də çəkmə sorğusu yaradılmasına uyğun olaraq edirsinizsə hadisə, onda SHA git tarixində gördüyümüz hashla uyğun gəlməyə bilər, çünki hərəkətlər/checkout hərəkəti PR-də blokadaya uğrayan hərəkətlərin qarşısını almaq üçün özünəməxsus hash yaradır.
Hər şey yaxşı alındısa, depoda paketlər bölməsini (https://github.com/antkorwin/github-actions/packages) açaraq yeni docker şəklini görəcəksiniz:
Orada həmçinin docker təsvirinin versiyalarının siyahısını görə bilərsiniz.
Yalnız serverimizi bu reyestrlə işləmək üçün konfiqurasiya etmək və xidməti yenidən başlatmaq qalır. Yəqin ki, başqa vaxt bunu systemd vasitəsilə necə etmək barədə danışacağam.
Monitorinq
Gəlin GitHub Actions-dan istifadə edərək tətbiqimiz üçün sağlamlıq yoxlamasının necə aparılacağına dair sadə seçimə baxaq. Yükləmə tətbiqimizdə aktuator var, ona görə də onun statusunu yoxlamaq üçün API yazmağa belə ehtiyacımız yoxdur; biz tənbəllər üçün artıq hər şeyi etdik. Yalnız ev sahibini çəkmək lazımdır: 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"}
Bizə lazım olan tək şey cron istifadə edərək serveri yoxlamaq üçün tapşırıq yazmaqdır və birdən bizə cavab verməsə, teleqramda bildiriş göndərəcəyik.
Əvvəlcə cron iş prosesini necə idarə edəcəyimizi anlayaq:
on:
schedule:
- cron: '*/5 * * * *'
Çox sadədir, mən hətta inana bilmirəm ki, Github-da veb-qancalara ümumiyyətlə uyğun gəlməyən hadisələr yarada bilərsiniz. Təfərrüatlar sənədlərdə var:
Gəlin serverin vəziyyətini curl vasitəsilə əl ilə yoxlayaq:
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"
Əvvəlcə serverin sorğuya cavab verdiyini dəyişəndə saxlayırıq, növbəti mərhələdə statusun UP olduğunu yoxlayırıq və əgər belə deyilsə, xəta ilə çıxırıq. Bir hərəkəti əllərinizlə "aşmaq" lazımdırsa, o zaman çıxış 1 - uyğun silah.
- 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 }}
Biz teleqrama yalnız əvvəlki addımda əməliyyat uğursuz olarsa göndəririk. Mesaj göndərmək üçün biz appleboy/telegram-action istifadə edirik; siz sənədlərdə bot nişanı və söhbət id-sini necə əldə etmək barədə oxuya bilərsiniz:
Github-da sirlərə yazmağı unutmayın: server üçün URL və teleqram botu üçün tokenlər.
Bonus trek - tənbəllər üçün JIRA
Söz verdim ki, biz JIRA-ya qayıdacağıq və biz də qayıtdıq. Yüzlərlə dəfə mən stend-uplarda bir vəziyyəti müşahidə etmişəm ki, tərtibatçılar bir funksiya yaratdılar, filialı birləşdirdilər, lakin məsələni JIRA-ya çəkməyi unutdular. Əlbəttə ki, bütün bunlar bir yerdə edilsəydi, daha asan olardı, amma əslində biz IDE-də kod yazırıq, budaqları bitbucket və ya GitHub-da birləşdiririk və sonra tapşırıqları Jira-ya sürükləyirik, bunun üçün yeni pəncərələr açmalıyıq. , bəzən yenidən daxil olun və s. Bundan sonra nə etməli olduğunuzu mükəmməl xatırladığınız zaman, lövhəni yenidən açmağın mənası yoxdur. Nəticədə, səhər standupda tapşırıqlar lövhəsini yeniləməyə vaxt sərf etməlisiniz.
GitHub də bu rutin tapşırıqda bizə kömək edəcək; yeni başlayanlar üçün biz çəkmə sorğusu göndərdiyimiz zaman problemləri avtomatik olaraq code_review sütununa sürükləyə bilərik. Sizə lazım olan tək şey filial adlandırma konvensiyasına əməl etməkdir:
[имя проекта]-[номер таска]-название
məsələn, "GitHub Actions" layihə açarı GA-dırsa, o zaman GA-8-jira-bot GA-8 tapşırığını həyata keçirmək üçün filial ola bilər.
JIRA ilə inteqrasiya Atlassian-ın hərəkətləri ilə işləyir, onlar mükəmməl deyil, deməliyəm ki, bəziləri mənim üçün ümumiyyətlə işləmədi. Ancaq biz yalnız mütləq işləyən və aktiv istifadə olunanları müzakirə edəcəyik.
Əvvəlcə JIRA-ya aşağıdakı hərəkətdən istifadə edərək daxil olmalısınız: 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 }}
Bunu etmək üçün JIRA-da bir token əldə etməlisiniz, bunun necə ediləcəyi burada təsvir edilmişdir:
Tapşırıq identifikatorunu filial adından çıxarırıq:
- 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 bazarında axtarış etsəniz, bu tapşırıq üçün bir hərəkət tapa bilərsiniz, lakin mən filialın adından istifadə edərək grep istifadə edərək eyni şeyi yazmalı oldum, çünki Atlassian-ın bu hərəkəti heç bir şəkildə mənim layihəmdə işləmək istəmədi. , orada nəyin səhv olduğunu anlamaq üçün - əllərinizlə eyni şeyi etməkdən daha uzun.
Təkcə çəkilmə sorğusu yaratarkən tapşırığı "Kod nəzərdən keçirmə" sütununa köçürmək qalır:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Bunun üçün GitHub-da xüsusi bir hərəkət var, ona lazım olan tək şey əvvəlki addımda əldə edilmiş məsələ ID-si və yuxarıda etdiyimiz JIRA-da icazədir.
Eyni şəkildə, GitHub iş axınından master və digər hadisələrə birləşdirilərkən tapşırıqları sürükləyə bilərsiniz. Ümumiyyətlə, hər şey sizin təsəvvürünüzdən və gündəlik prosesləri avtomatlaşdırmaq istəyinizdən asılıdır.
Tapıntılar
Klassik DEVOPS diaqramına baxsanız, bəlkə də işləməkdən başqa bütün mərhələləri əhatə etdik, düşünürəm ki, cəhd etsəniz, yardım masası sistemi ilə inteqrasiya üçün bazarda bəzi hərəkətlər tapa bilərsiniz, buna görə də boru kəmərinin çevrildiyini güman edəcəyik. müfəssəl olmalıdır və ondan istifadə əsasında nəticə çıxarmaq olar.
Pros:
- Bütün hallar üçün hazır hərəkətləri olan bazar, bu çox gözəldir. Onların əksəriyyətində oxşar problemi necə həll edəcəyinizi başa düşmək üçün mənbə koduna baxa və ya müəllifə birbaşa GitHub deposunda xüsusiyyət sorğusu göndərə bilərsiniz.
- Montaj üçün hədəf platformanın seçilməsi: Linux, mac os, windows olduqca maraqlı bir xüsusiyyətdir.
- Github Paketləri əla şeydir, bütün infrastrukturu bir yerdə saxlamaq rahatdır, müxtəlif pəncərələrdən keçmək lazım deyil, hər şey bir və ya iki siçan klik radiusundadır və GitHub Actions ilə mükəmməl inteqrasiya olunub. Pulsuz versiyada Docker reyestrinə dəstək də yaxşı bir üstünlükdür.
- GitHub qurma qeydlərində sirləri gizlədir, ona görə də parolları və tokenləri saxlamaq üçün istifadə etmək o qədər də qorxulu deyil. Bütün təcrübələrim zamanı konsolda sirri heç vaxt saf formada görə bilmədim.
- Açıq mənbə layihələri üçün pulsuz
Eksiler:
- YML, yaxşı, mən onu sevmirəm. Belə bir axınla işləyərkən məndə ən çox görülən commit mesajı “yml formatını düzəldin” mesajıdır, sonra harasa tab qoymağı unudursunuz və ya onu səhv sətirə yazırsınız. Ümumiyyətlə, iletki və xətkeşlə ekran qarşısında oturmaq ən xoş təcrübə deyil.
- DEBUG, öhdəçiliklər ilə axının sazlanması, yenidən qurulmasının icrası və konsola çıxış həmişə əlverişli deyil, lakin bu, daha çox “sizi həddən artıq aşırdınız” kateqoriyasına aiddir; siz hər hansı bir şeyi sazlaya bildiyiniz zaman rahat IDEA ilə işləməyə öyrəşmisiniz. .
- Docker-ə büksəniz, hərəkətinizi hər hansı bir şeyə yaza bilərsiniz, lakin yalnız javascript yerli olaraq dəstəklənir, əlbəttə ki, bu zövq məsələsidir, amma js əvəzinə başqa bir şeyə üstünlük verərdim.
Xatırlatmaq istəyirəm ki, bütün skriptləri olan depo buradadır:
Gələn həftə ilə birlikdə çıxış edəcəm Heisenbug 2020 Piter konfransında. Mən sizə yalnız test məlumatlarını hazırlayarkən səhvlərdən necə qaçınacağınızı deyil, həm də Java proqramlarında məlumat dəstləri ilə işləmək sirlərimi bölüşəcəyəm!
Mənbə: www.habr.com