3-bo‘lim

Hodisalar va triggerlar

on kaliti, push va pull_request, tarmoq va yo'l filtrlari, jadval bo'yicha ishga tushirish va keraksiz ishlarni to'xtatish.

🕑 11 daqiqa o‘qish 📄 931 so‘z 👁 0 marta ko‘rilgan
Ushbu bo‘lim mundarijasi
  1. Eng ko'p ishlatiladigan hodisalar
  2. push va pull_request - asosiy juftlik
  3. Tarmoq va teg filtrlari
  4. Yo'l bo'yicha filtr - eng foydali tejamkorlik
  5. Jadval bo'yicha ishga tushirish
  6. Qo'lda ishga tushirish va kiritmalar
  7. Hodisa turlari (types)
  8. Keraksiz ishlarni to'xtatish
  9. Hodisa haqida ma'lumot
  10. Xulosa

Quvur qachon ishlashi kerak? Har bir kommitda? Faqat asosiy tarmoqda? Har kecha? Bunga on: kaliti javob beradi va u workflow faylidagi eng muhim qarorlardan biri.

Eng ko'p ishlatiladigan hodisalar #

HodisaQachon ishlaydiOdatda nima uchun
pushKod tarmoqqa yuborilgandaTestlar, qurish
pull_requestPR ochilganda yoki yangilangandaKodni birlashtirishdan oldin tekshirish
workflow_dispatchOdam tugma bosgandaDeploy, bir martalik vazifalar
scheduleVaqt jadvali bo'yichaKechasi to'liq testlar, zaxira
releaseReliz chop etilgandaPaket nashr qilish
issues, issue_commentMuammo yoki izoh bilan ishlangandaAvtomatik javob, yorliq qo'yish

push va pull_request - asosiy juftlik #

YAML
name: Testlar

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "Testlar ishlayapti"

Bu eng keng tarqalgan sozlama. U shuni bildiradi:

  • main ga to'g'ridan-to'g'ri push bo'lganda - tekshir;
  • main ga qaratilgan PR ochilganda yoki unga yangi kommit qo'shilganda - tekshir.
Qaysi hodisa qachon yuz beradi main xususiyat push -> ishlaydi push -> ishlaydi PR ochildi pull_request -> ishlaydi birlashtirildi push -> ishlaydi Ikkalasini yozsangiz, PR ichidagi kommitlar ikki marta emas, bir marta tekshiriladi
Xususiyat tarmog'idagi kommitlar, PR va birlashtirish - har biri alohida hodisa
Nega ikkalasi ham kerak

Faqat push yozilsa - PR sahifasida tekshiruv natijasi ko'rinmaydi. Faqat pull_request yozilsa - main ga to'g'ridan-to'g'ri tushgan kod tekshirilmay qoladi.

Ikkalasi birga yozilganda GitHub takrorlanishning oldini oladi: PR ga tegishli tarmoqdagi kommit uchun bitta ishga tushirish bo'ladi.

Tarmoq va teg filtrlari #

YAML
on:
  push:
    branches:
      - main
      - 'reliz/**'
    branches-ignore:
      - 'qoralama/**'
    tags:
      - 'v*'
FiltrMa'nosi
branches: [main]Faqat shu tarmoq
branches: ['reliz/**']reliz/ bilan boshlanadigan hammasi
branches-ignoreSanab o'tilganlardan tashqari hammasi
tags: ['v*']v1.0.0 kabi teglar

branches va branches-ignore ni bitta hodisada birga ishlatib bo'lmaydi - bittasini tanlang.

Yo'l bo'yicha filtr - eng foydali tejamkorlik #

Hujjatdagi bitta harf o'zgargani uchun butun test to'plamini ishga tushirish keraksiz. paths buni hal qiladi:

YAML
on:
  push:
    paths:
      - 'src/**'
      - 'package.json'
      - '.github/workflows/**'
    paths-ignore:
      - '**.md'
      - 'docs/**'
Ikkisini birga yozmang

paths va paths-ignore ham bitta hodisada birga ishlamaydi. Odatda bittasi yetarli:

  • kod papkasi aniq bo'lsa - paths ishlating;
  • loyiha aralash bo'lsa - paths-ignore bilan hujjatlarni chiqarib tashlang.

Jadval bo'yicha ishga tushirish #

YAML
on:
  schedule:
    - cron: '0 3 * * *'

Cron formati besh maydondan iborat:

Natija
┌─ daqiqa (0-59)
│ ┌─ soat (0-23)
│ │ ┌─ oyning kuni (1-31)
│ │ │ ┌─ oy (1-12)
│ │ │ │ ┌─ hafta kuni (0-6, 0 - yakshanba)
│ │ │ │ │
0 3 * * *
YozuvMa'nosi
0 3 * * *Har kuni soat 03:00 da
*/15 * * * *Har 15 daqiqada
0 9 * * 1Har dushanba soat 09:00 da
0 0 1 * *Har oyning birinchi kuni
Jadval vaqti - UTC

GitHub Actions dagi cron har doim UTC bo'yicha ishlaydi. Toshkent vaqti UTC+5, ya'ni:

ToshkentUTCCron
08:0003:000 3 * * *
12:0007:000 7 * * *
00:0019:00 (oldingi kun)0 19 * * *

Yana ikki narsani biling: jadval bo'yicha ishga tushirish faqat asosiy tarmoqdan o'qiladi va u aniq daqiqada emas, bir necha daqiqa kechikib boshlanishi mumkin - GitHub yuklama bo'yicha navbatga qo'yadi.

Qo'lda ishga tushirish va kiritmalar #

workflow_dispatch ga parametr berish mumkin - shunda tugma bosilganda forma chiqadi:

YAML
on:
  workflow_dispatch:
    inputs:
      muhit:
        description: 'Qaysi muhitga'
        required: true
        default: 'sinov'
        type: choice
        options:
          - sinov
          - ishlab-chiqarish
      izoh:
        description: 'Qisqacha izoh'
        required: false
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Tanlovni ko'rsatish
        run: |
          echo "Muhit: ${{ inputs.muhit }}"
          echo "Izoh:  ${{ inputs.izoh }}"
Natija
Muhit: ishlab-chiqarish
Izoh:  qo'lda chiqarilgan tuzatish

Hodisa turlari (types) #

Ba'zi hodisalarning ichki turlari bor. Masalan, PR yopilganda emas, faqat birlashtirilganda ishlashi kerak bo'lsa:

YAML
on:
  pull_request:
    types: [opened, synchronize, reopened]
TurQachon
openedPR yangi ochildi
synchronizePR ga yangi kommit qo'shildi
reopenedYopilgan PR qayta ochildi
closedPR yopildi (birlashtirilgan yoki yo'q)
ready_for_reviewQoralama PR tayyor deb belgilandi

Yozilmasa, pull_request uchun standart holat opened, synchronize va reopened bo'ladi - ko'pchilik uchun aynan shu kerak.

Keraksiz ishlarni to'xtatish #

PR ga ketma-ket uchta kommit yuborsangiz, uchta ishga tushirish boshlanadi - holbuki faqat oxirgisi muhim. concurrency eskisini bekor qiladi:

YAML
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
Uchta kommit - nechta ishga tushirish concurrency yo'q kommit 1 - to'liq kommit 2 - to'liq kommit 3 - to'liq 3x vaqt concurrency bilan bekor bekor kommit 3 - to'liq 1x vaqt
Eski ishga tushirishlar bekor qilinadi - navbat ham, hisob ham tejaladi
Ishlab chiqarishga deploy qiladigan quvurda cancel-in-progress yoqmang

Deploy o'rtasida bekor qilingan ishga tushirish serverni yarim yangilangan holatda qoldirishi mumkin: fayllar ko'chirilgan, lekin xizmat qayta ishga tushirilmagan.

Bunday quvurlar uchun navbatni saqlang:

YAML
concurrency:
  group: deploy-ishlab-chiqarish
  cancel-in-progress: false

Shunda ikkinchi deploy birinchisi tugashini kutadi.

Hodisa haqida ma'lumot #

Har bir ishga tushirishda github konteksti mavjud:

YAML
      - name: Hodisa haqida
        run: |
          echo "Hodisa:  ${{ github.event_name }}"
          echo "Tarmoq:  ${{ github.ref_name }}"
          echo "Kommit:  ${{ github.sha }}"
          echo "Muallif: ${{ github.actor }}"
Natija
Hodisa:  push
Tarmoq:  main
Kommit:  9f2c1ab7e4d5c3b8a16f0e7d2c9b4a8f5e3d1c06
Muallif: husanboy
O'zgaruvchiNima beradi
github.event_nameHodisa nomi: push, pull_request ...
github.ref_nameTarmoq yoki teg nomi
github.shaKommitning to'liq xeshi
github.actorIshga tushirishni boshlagan foydalanuvchi
github.repositoryegasi/repozitoriy ko'rinishida
Amaliy topshiriq
  1. push va pull_request hodisalarini bitta workflow ga qo'shing.
  2. Yangi tarmoq ochib, unga kommit yuboring va qaysi hodisa ishlaganini kuzating.
  3. Shu tarmoqdan PR oching - endi qaysi hodisa ishladi?
  4. branches: [main] filtri bilan boshqa tarmoqda ishlamasligini tekshiring.
  5. paths-ignore bilan **.md fayllarini chiqarib tashlang va faqat README ni o'zgartirib push qiling.
  6. Har kuni Toshkent vaqti bilan 09:00 da ishlaydigan schedule yozing.
  7. workflow_dispatch ga muhit tanlovini qo'shing va tugma orqali ishga tushiring.
  8. github kontekstidagi beshta qiymatni jurnalga chiqaring.
  9. concurrency qo'shib, ketma-ket ikkita kommit yuboring va birinchisi bekor bo'lishini ko'ring.
  10. Deploy quvuri uchun nega cancel-in-progress: false kerakligini uch jumlada yozing.

Xulosa #

  • on: kaliti quvur qachon ishlashini belgilaydi - bu eng muhim qarorlardan biri.
  • Odatiy juftlik: push + pull_request, ikkalasi main ga filtrlangan holda.
  • branches, tags va paths keraksiz ishga tushirishlarni kesadi.
  • branches va branches-ignore (xuddi paths va paths-ignore kabi) birga ishlatilmaydi.
  • schedule UTC bo'yicha ishlaydi: Toshkentdagi 08:00 - bu 0 3 * * *.
  • Jadval faqat asosiy tarmoqdan o'qiladi va bir necha daqiqa kechikishi mumkin.
  • workflow_dispatch tugma beradi, inputs esa unga forma qo'shadi.
  • types hodisaning qaysi holatida ishlashini aniqlaydi.
  • concurrency eski ishga tushirishlarni bekor qilib, navbat va hisobni tejaydi.
  • Deploy quvurida cancel-in-progress: false bo'lishi kerak - yarim bajarilgan deploy xavfli.

Keyingi bo'limda job, step va runner'lar bilan chuqurroq tanishamiz.

Xatolik topdingizmi?

Imlo xatosi, ishlamaydigan kod yoki noto‘g‘ri ma‘lumotni ko‘rsangiz - bizga xabar bering. Har bir xabar administrator tomonidan ko‘rib chiqiladi.