Men tez-tez Java-da loyihalarni qurish uchun quvur qurishim kerak. Ba'zan ochiq manba, ba'zan esa yo'q. Yaqinda men ba'zi omborlarimni Travis-CI va TeamCity-dan GitHub Actions-ga ko'chirishga qaror qildim va bu shundan kelib chiqdi.
Biz nimani avtomatlashtiramiz?
Birinchidan, bizga avtomatlashtiradigan loyiha kerak, keling Spring boot / Java 11 / Maven da kichik dastur yarataylik. Ushbu maqolaning maqsadlari uchun bizni dastur mantig'i umuman qiziqtirmaydi; ilova atrofidagi infratuzilma biz uchun muhim, shuning uchun biz uchun oddiy REST API kontrolleri kifoya qiladi.
Manbalarni bu yerda ko'rishingiz mumkin: Quvurni qurishning barcha bosqichlari ushbu loyiha uchun tortishish so'rovlarida aks ettirilgan.
JIRA va rejalashtirish
Shuni aytish kerakki, biz odatda JIRA dan muammolarni kuzatuvchi sifatida foydalanamiz, shuning uchun keling, ushbu loyiha uchun alohida kengash yaratamiz va u erga birinchi muammolarni qo'shamiz:
Birozdan keyin biz JIRA va GitHub birgalikda qanday qiziqarli narsalarni taklif qilishiga qaytamiz.
Biz loyihani yig'ishni avtomatlashtiramiz
Bizning sinov loyihamiz maven orqali qurilgan, shuning uchun uni qurish juda oddiy, bizga faqat mvn toza paketi kerak bo'ladi.
Buni Github Actions yordamida amalga oshirish uchun biz omborda ish jarayonini tavsiflovchi fayl yaratishimiz kerak bo'ladi, buni oddiy yml fayli bilan qilish mumkin, men "yml dasturlashni" yoqtiraman deb ayta olmayman, lekin nima qilishimiz mumkin - biz buni .github/ directory workflow/ build.yml faylida qilamiz, unda biz asosiy filialni qurishdagi harakatlarni tasvirlaymiz:
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 bizning skriptimiz ishga tushiriladigan tadbirning tavsifi.
yoniq: pull_request/push — masterga har safar surish qilinganda va tortish so‘rovlari yaratilganda ushbu ish jarayonini ishga tushirish kerakligini ko‘rsatadi.
Quyida vazifalarning tavsifi (ish o'rinlari) va bajarish bosqichlari (qadamlar) har bir vazifa uchun.
ishlaydi - bu erda biz maqsadli operatsion tizimni tanlashimiz mumkin, ajablanarlisi shundaki, siz hatto Mac OS ni ham tanlashingiz mumkin, ammo shaxsiy omborlarda bu juda qimmat (Linux bilan solishtirganda).
foydalanish boshqa amallarni qayta ishlatishga imkon beradi, masalan, actions/setup-java amalidan foydalanib, biz Java 11 uchun muhitni oʻrnatamiz.
Yordamida bilan biz harakatni ishga tushiradigan parametrlarni belgilashimiz mumkin, asosan bu argumentlar harakatga uzatiladi.
Maven bilan loyiha qurishni ishga tushirish qoladi: run: mvn -B clean package bayroq -B Bizga interaktiv bo'lmagan rejim kerakligini aytadi, shunda maven bizdan to'satdan biror narsa so'ramoqchi emas
Ajoyib! Endi, har safar ustaga topshirganingizda, loyihani qurish boshlanadi.
Sinovlarni avtomatlashtirish
Yig'ish yaxshi, lekin aslida loyiha xavfsiz tarzda yig'ilishi mumkin, lekin ishlamaydi. Shuning uchun keyingi qadam test sinovlarini avtomatlashtirishdir. Bundan tashqari, PR tekshiruvini o'tkazayotganda testlardan o'tish natijalarini ko'rish juda qulay - siz aniq bilasizki, testlar o'tadi va hech kim birlashishdan oldin o'z filialini ishga tushirishni unutmagan.
Biz tortishish so'rovini yaratishda testlarni o'tkazamiz va masterga birlashamiz va shu bilan birga kodni qamrab olish bo'yicha hisobot yaratishni qo'shamiz.
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 }}
Sinovlarni qoplash uchun men jacoco plagini bilan birgalikda codecov-dan foydalanaman. codecovning o'z harakati bor, lekin bizning tortishish so'rovimiz bilan ishlash uchun unga token kerak:
${{ secrets.CODECOV_TOKEN }} — biz bu konstruksiyani bir necha bor ko‘ramiz, sirlar GitHub-da sirlarni saqlash mexanizmi, biz u yerga parollar/tokenlar/hostlar/urllar va ombor kodlari bazasiga kiritilmasligi kerak bo‘lgan boshqa ma’lumotlarni yozishimiz mumkin.
GitHub-dagi ombor sozlamalarida sirlarga o'zgaruvchini qo'shishingiz mumkin:
Siz tokenni olishingiz mumkin GitHub orqali avtorizatsiyadan so'ng, umumiy loyihani qo'shish uchun quyidagi havolaga o'tishingiz kifoya: /[repo nomi]. Shaxsiy omborni ham qo'shish mumkin, buning uchun siz Github-da ilovaga kodkov huquqlarini berishingiz kerak.
POM fayliga jacoco plaginini qo'shing:
<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>
Endi codecov boti har bir tortishish so'rovimizni kiritadi va qamrovni o'zgartirish grafigini qo'shadi:
Keling, statik analizatorni qo'shamiz
Ko'pgina ochiq manba loyihalarimda statik kod tahlili uchun sonar bulutidan foydalanaman, travis-ci-ga ulanish juda oson. Shunday qilib, xuddi shunday qilish uchun GitHub Actions-ga o'tishda mantiqiy qadam. Aktsiya bozori juda zo'r narsa, lekin bu safar u meni biroz tushkunlikka tushirdi, chunki odat bo'yicha men kerakli harakatni topdim va uni ish jarayoniga qo'shdim. Ammo ma'lum bo'lishicha, sonar maven yoki gradle-da loyihalarni tahlil qilish bo'yicha harakatni qo'llab-quvvatlamaydi. Albatta, bu hujjatda yozilgan, lekin kim o'qiydi?!
Harakat orqali buni amalga oshirish mumkin emas, shuning uchun biz buni mvn plagini orqali qilamiz:
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 - dan olish mumkin va siz uni sirlarda ro'yxatdan o'tkazishingiz kerak. GITHUB_TOKEN - bu GitHub ishlab chiqaradigan o'rnatilgan token bo'lib, uning yordamida sonarcloud[bot] bizga pull so'rovlarida xabarlar qoldirish uchun Git-ga kirishi mumkin.
Dsonar.projectKey — sonardagi loyiha nomi, uni loyiha sozlamalarida koʻrishingiz mumkin.
Dsonar.organization — GitHub dan tashkilot nomi.
Biz tortishish so'rovini yuboramiz va sharhlarda sonarcloud[bot] kelishini kutamiz:
Chiqarishni boshqarish
Qurilish sozlandi, sinovlar o'tkazildi va biz chiqarishimiz mumkin. Keling, GitHub Actions relizlarni boshqarishni qanday osonlashtirishi mumkinligini ko'rib chiqaylik.
Ishda menda kod bazasi bitbuketda bo'lgan loyihalarim bor (hamma narsa o'sha hikoyadagiga o'xshaydi: "Men kun davomida bitbucketga yozaman, kechasi GitHubga topshiraman"). Afsuski, bitbucket-da o'rnatilgan relizlarni boshqarish vositalari mavjud emas. Bu muammo, chunki har bir nashr uchun siz qo'lda sahifa yaratishingiz va nashrga kiritilgan barcha xususiyatlarni u erga tashlashingiz, aql saroylarini, jiradagi vazifalarni, ombordagi vazifalarni qidirishingiz kerak. Xato qilish uchun juda ko'p imkoniyatlar mavjud, siz biror narsani unutishingiz yoki oxirgi marta chiqarilgan narsani kiritishingiz mumkin, ba'zida tortishish so'rovini qanday tasniflash tushunarsiz - bu xususiyatmi yoki xatolarni tuzatishmi yoki testlarni tahrirlashmi yoki infratuzilmaviy narsa.
GitHub harakatlari bizga qanday yordam berishi mumkin? Ajoyib harakat bor - relizlar loyihasini tuzuvchi, u sizga tortib olish so'rovlari toifalarini o'rnatish va ularni avtomatik ravishda relizlar qaydlari faylida guruhlash uchun relizlar qaydlari fayl shablonini o'rnatish imkonini beradi:
Hisobotni o'rnatish uchun namuna shablon (.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
Reliz qoralamasini yaratish uchun skript qo'shing (.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 buyon barcha tortishish so'rovlari avtomatik ravishda reliz yozuvlarida to'planadi - sehr!
Bu erda savol tug'ilishi mumkin: agar ishlab chiquvchilar PRga teg qo'yishni unutib qo'yishsa-chi? Keyin uni qaysi toifaga qo'yish aniq emas va yana siz uni qo'lda, har bir PR bilan alohida hal qilishingiz kerak bo'ladi. Ushbu muammoni hal qilish uchun biz boshqa amaldan foydalanishimiz mumkin - yorliq tekshiruvi - u tortish so'rovida teglar mavjudligini tekshiradi. Agar kerakli teglar bo'lmasa, tekshirish muvaffaqiyatsiz bo'ladi va biz tortishish so'rovimizda bu haqda xabarni ko'ramiz.
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'
Endi har qanday pull-so'rov teglardan biri bilan belgilanishi kerak: type:fix, type:features, type:documentation, type:tests, type:config.
Pull so'rovlarini avtomatik izohlash
Biz tortishish so'rovlari bilan samarali ishlash kabi mavzuga to'xtalganimiz sababli, labeler kabi harakat haqida gapirishga arziydi, u PR-ga teglarni qaysi fayllar o'zgartirilganiga qarab qo'yadi. Masalan, biz katalogdagi o'zgarishlarni o'z ichiga olgan har qanday tortish so'rovini [qurish] sifatida belgilashimiz mumkin .github/workflow.
Uni ulash juda oddiy:
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 }}
Shuningdek, bizga loyiha kataloglari va tortishish so'rovi mavzulari o'rtasidagi yozishmalarni tavsiflovchi fayl kerak:
theme:build:
- ".github/**"
- "pom.xml"
- ".travis.yml"
- ".gitignore"
- "Dockerfile"
theme:code:
- "src/main/*"
theme:tests:
- "src/test/*"
theme:documentation:
- "docs/**"
theme:TRASH:
- ".idea/**"
- "target/**"
Men tortishish soʻrovlarida yorliqlarni avtomatik ravishda joylashtiradigan amalni kerakli teglar mavjudligini tekshiradigan amal bilan bogʻlay olmadim; match-label bot qoʻshgan yorliqlarni koʻrishni istamaydi. Ikkala bosqichni birlashtirgan o'zingizning harakatingizni yozish osonroq ko'rinadi. Ammo bu shaklda ham foydalanish juda qulay, siz tortish so'rovini yaratishda ro'yxatdan yorliqni tanlashingiz kerak.
Joylashtirish vaqti keldi
Men GitHub Actions orqali (ssh orqali, scp orqali va docker-hub yordamida) bir nechta joylashtirish variantlarini sinab ko'rdim va shuni aytishim mumkinki, siz quvur liniyasi qanchalik egri bo'lishidan qat'i nazar, ikkilik faylni serverga yuklash yo'lini topasiz. hisoblanadi.
Menga butun infratuzilmani bir joyda saqlash varianti yoqdi, shuning uchun GitHub paketlarini qanday joylashtirishni ko'rib chiqaylik (bu ikkilik kontent, npm, jar, docker uchun ombor).
Docker tasvirini yaratish va uni GitHub paketlarida nashr qilish uchun 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 }}"
Birinchidan, biz ilovamizning JAR faylini yaratishimiz kerak, shundan so'ng biz GitHub docker registriga yo'lni va rasmimiz nomini hisoblaymiz. Bu erda biz hali uchratmagan bir nechta fokuslar mavjud:
- kabi konstruksiya: echo “::set-output name=NAME::VALUE” oʻzgaruvchining qiymatini joriy bosqichda oʻrnatishga imkon beradi, shunda u boshqa barcha bosqichlarda oʻqilishi mumkin.
- oldingi bosqichda oʻrnatilgan oʻzgaruvchining qiymatini ushbu bosqich identifikatori orqali olishingiz mumkin: ${{ steps.global_env.outputs.DOCKERHUB_IMAGE_NAME }}
- Standart GITHUB_REPOSITORY o'zgaruvchisi ombor nomini va uning egasini ("egasi/repo-nomi") saqlaydi. Ushbu qatordan ombor nomidan tashqari hamma narsani kesish uchun biz bash sintaksisidan foydalanamiz: ${GITHUB_REPOSITORY#*/}
Keyin biz docker tasvirini yaratishimiz kerak:
docker build -t "docker.pkg.github.com/antkorwin/github-actions/github-actions:latest"
Ro'yxatga olish kitobiga kiring:
docker login docker.pkg.github.com -u $GITHUB_ACTOR -p ${{secrets.GITHUB_TOKEN}}
Va rasmni GitHub Packages Repository-ga nashr eting:
docker push "docker.pkg.github.com/antkorwin/github-actions/github-actions"
Tasvirning versiyasini ko'rsatish uchun biz majburiyatning SHA xeshidagi birinchi raqamlardan foydalanamiz - GITHUB_SHA bu erda nuanslar ham mavjud, agar siz bunday tuzilmalarni nafaqat masterga birlashganda, balki tortish so'rovini yaratishga ko'ra ham qilsangiz. hodisa, keyin SHA biz git tarixida ko'rgan xeshga mos kelmasligi mumkin, chunki harakatlar/checkout harakati PRda blokirovka qiluvchi harakatlardan qochish uchun o'ziga xos xeshni yaratadi.
Agar hamma narsa yaxshi bo'lsa, omborda paketlar bo'limini (https://github.com/antkorwin/github-actions/packages) ochib, siz yangi docker tasvirini ko'rasiz:
U erda siz docker tasvirining versiyalari ro'yxatini ham ko'rishingiz mumkin.
Faqat serverimizni ushbu ro'yxatga olish kitobi bilan ishlash uchun sozlash va xizmatni qayta ishga tushirish qoladi. Buni systemd orqali qanday qilish haqida boshqa safar gaplashaman.
Monitoring
Keling, GitHub Actions yordamida ilovamizning sog'lig'ini tekshirishning oddiy variantini ko'rib chiqaylik. Bizning yuklash ilovamizda aktuator mavjud, shuning uchun uning holatini tekshirish uchun API yozishimiz shart emas; biz dangasalar uchun hamma narsani qildik. Siz shunchaki xostni tortib olishingiz kerak: 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"}
Bizga cron yordamida serverni tekshirish uchun topshiriq yozish kerak, agar to'satdan bizga javob bermasa, telegram orqali bildirishnoma yuboramiz.
Birinchidan, keling, cron ish jarayonini qanday boshqarishni aniqlaymiz:
on:
schedule:
- cron: '*/5 * * * *'
Hammasi oddiy, men hatto Github-da vebhuklarga umuman to'g'ri kelmaydigan voqealarni yaratishingiz mumkinligiga ishonmayman. Tafsilotlar hujjatlarda:
Curl orqali server holatini qo'lda tekshiramiz:
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"
Birinchidan, biz server so'rovga javob bergan narsani o'zgaruvchiga saqlaymiz, keyingi bosqichda holat UP ekanligini tekshiramiz va agar bunday bo'lmasa, xato bilan chiqamiz. Agar siz harakatni qo'llaringiz bilan "bosib qo'yishingiz" kerak bo'lsa, unda chiqish 1 - mos qurol.
- 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 telegramga faqat oldingi bosqichdagi harakat muvaffaqiyatsizlikka uchragan taqdirdagina yuboramiz. Xabar yuborish uchun biz appleboy/telegram-action-dan foydalanamiz; bot tokenini va chat identifikatorini qanday olish haqida hujjatlarda o‘qishingiz mumkin:
Github-dagi sirlarga yozishni unutmang: server uchun URL va telegram bot uchun tokenlar.
Bonus trek - dangasalar uchun JIRA
Men JIRAga qaytamiz, deb va'da berdim va biz qaytdik. Yuzlab marta men stend-uplarda vaziyatni kuzatganman, qachonki ishlab chiquvchilar xususiyat yaratgan, filialni birlashtirgan, lekin masalani JIRA-ga tortishni unutgan. Albatta, agar bularning barchasi bir joyda amalga oshirilsa, osonroq bo'lar edi, lekin aslida biz IDE-da kod yozamiz, filiallarni bitbucket yoki GitHub-ga birlashtiramiz, so'ngra vazifalarni Jira-ga tortamiz, buning uchun biz yangi oynalarni ochishimiz kerak. , ba'zan qayta kiring va hokazo. Keyinchalik nima qilish kerakligini yaxshi eslab qolsangiz, taxtani yana ochishning ma'nosi yo'q. Natijada, ertalab stendda siz vazifalar panelini yangilashga vaqt sarflashingiz kerak.
GitHub ham bizga ushbu odatiy vazifani bajarishda yordam beradi; yangi boshlanuvchilar uchun biz tortishish so'rovini yuborganimizda, muammolarni avtomatik ravishda code_review ustuniga tortib olishimiz mumkin. Siz qilishingiz kerak bo'lgan yagona narsa filial nomlash konventsiyasiga amal qilishdir:
[имя проекта]-[номер таска]-название
masalan, agar "GitHub Actions" loyiha kaliti GA bo'lsa, u holda GA-8-jira-bot GA-8 topshirig'ini amalga oshirish uchun filial bo'lishi mumkin.
JIRA bilan integratsiya Atlassian-dan harakatlar orqali ishlaydi, ular mukammal emas, aytishim kerakki, ularning ba'zilari men uchun umuman ishlamadi. Ammo biz faqat aniq ishlaydigan va faol foydalaniladigan narsalarni muhokama qilamiz.
Avval JIRA-ga quyidagi amal yordamida kirishingiz kerak: 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 }}
Buning uchun siz JIRA da token olishingiz kerak, buni qanday qilish bu yerda tasvirlangan:
Biz filial nomidan vazifa identifikatorini chiqaramiz:
- 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}}
Agar siz GitHub bozorida qidirsangiz, bu vazifa uchun amalni topishingiz mumkin, lekin men grep yordamida filial nomidan foydalanib, xuddi shu narsani yozishim kerak edi, chunki Atlassian'ning bu harakati mening loyihamda hech qanday tarzda ishlashni xohlamadi. , u erda nima noto'g'ri ekanligini aniqlash uchun - qo'llaringiz bilan bir xil ishni qilishdan ko'ra uzoqroq.
Qolgan narsa, tortishish so'rovini yaratishda vazifani "Kodni ko'rib chiqish" ustuniga o'tkazishdir:
- name: Transition issue
if: ${{ success() }}
uses: atlassian/gajira-transition@master
with:
issue: ${{ steps.find_issue.outputs.ISSUE_ID }}
transition: "Code review"
Buning uchun GitHub-da maxsus harakat mavjud, unga faqat oldingi bosqichda olingan muammo identifikatori va biz yuqorida qilgan JIRA avtorizatsiyasi kerak bo'ladi.
Xuddi shu tarzda, siz GitHub ish oqimidagi master va boshqa hodisalarga birlashganda vazifalarni sudrab olishingiz mumkin. Umuman olganda, barchasi sizning tasavvuringizga va muntazam jarayonlarni avtomatlashtirish istagiga bog'liq.
topilmalar
Agar siz klassik DEVOPS diagrammasiga qarasangiz, biz barcha bosqichlarni qamrab oldik, ehtimol operatsiyadan tashqari, menimcha, agar urinib ko'rsangiz, yordam stoli tizimi bilan integratsiya qilish uchun bozorda biron bir harakatni topishingiz mumkin, shuning uchun biz quvur liniyasi aylangan deb taxmin qilamiz. puxta va undan foydalanish asosida xulosalar chiqarish mumkin.
Taroziga soling:
- Barcha holatlar uchun tayyor harakatlar bilan bozor, bu juda zo'r. Ularning aksariyatida siz shunga o'xshash muammoni qanday hal qilishni tushunish uchun manba kodiga qarashingiz yoki muallifga to'g'ridan-to'g'ri GitHub omborida xususiyat so'rovini yuborishingiz mumkin.
- Yig'ish uchun maqsadli platformani tanlash: Linux, mac os, windows - bu juda qiziq xususiyat.
- Github paketlari - bu ajoyib narsa, butun infratuzilmani bir joyda saqlash qulay, siz turli oynalar orqali kezishingiz shart emas, hamma narsa sichqonchani bir yoki ikki marta bosish radiusida joylashgan va GitHub Actions bilan mukammal birlashtirilgan. Bepul versiyada Docker registrini qo'llab-quvvatlash ham yaxshi afzallikdir.
- GitHub qurilish jurnallarida sirlarni yashiradi, shuning uchun parollar va tokenlarni saqlash uchun foydalanish unchalik qo'rqinchli emas. Barcha tajribalarim davomida men hech qachon konsolda sirni sof shaklda ko'ra olmadim.
- Ochiq kodli loyihalar uchun bepul
Kamchiliklari:
- YML, yaxshi, men uni yoqtirmayman. Bunday oqim bilan ishlaganda, menda eng ko'p uchraydigan majburiyat xabari "yml formatini tuzatish" bo'lib, keyin siz biror joyga yorliq qo'yishni unutasiz yoki uni noto'g'ri qatorga yozasiz. Umuman olganda, protraktor va o'lchagich bilan ekran oldida o'tirish eng yoqimli tajriba emas.
- DEBUG, majburiyatlar bilan oqimni disk raskadrovka qilish, qayta qurishni ishga tushirish va konsolga chiqish har doim ham qulay emas, lekin bu ko'proq "siz o'tib ketdingiz" toifasiga kiradi; siz har qanday narsani tuzatishingiz mumkin bo'lsa, qulay IDEA bilan ishlashga odatlangansiz. .
- Agar siz uni Docker-ga o'rab qo'ysangiz, har qanday narsaga o'z harakatingizni yozishingiz mumkin, lekin faqat JavaScript-ni qo'llab-quvvatlaydi, albatta, bu ta'mga bog'liq, lekin men JS o'rniga boshqa narsani afzal ko'raman.
Sizga eslatib o'tamanki, barcha skriptlar bilan ombor bu erda:
Keyingi hafta men bilan birga chiqish qilaman Heisenbug 2020 Piter konferentsiyasida. Men sizga nafaqat test ma'lumotlarini tayyorlashda xatolikka yo'l qo'ymaslik, balki Java dasturlarida ma'lumotlar to'plami bilan ishlash sirlari bilan o'rtoqlashaman!
Manba: www.habr.com