GitHub Actions: birinchi CI workflow — har push'da avtomatik tekshiruv

Qisqacha: CI (uzluksiz integratsiya) — har push va Pull Request'da kodni GitHub serverida avtomatik tekshirish. GitHub Actions'da u .github/workflows/ papkasidagi YAML fayl bilan yoziladi: on — qachon ishga tushadi, jobs — qaysi ishlar, runs-on — qaysi kompyuterda, steps — qaysi qadamlar (actions/checkout, actions/setup-node, npm ci, npm run check). Natija PR'da yashil yoki qizil X bo'lib chiqadi. Rulesetda uni majburiy qilsangiz, qizil PR main ga qo'shilmaydi. Public repolarda bepul.

Bu darsda

• CI nima ekanini va workflow, job, runner, step, action so'zlarini tushuntira olasiz.
• YAML sintaksisini o'qiysiz va birinchi workflow faylini yozasiz.
• actions/checkout, actions/setup-node (keshi bilan), npm ci va npm run check qadamlarini tushunasiz.
• PR'dagi yashil va qizil natijani gh run watch, gh pr checks va loglar orqali o'qiysiz.
• Tekshiruvni rulesetda majburiy status check qilasiz — qizil PR merge bo'lmaydi.

Oldin bilishingiz kerak: GitHub CLI (gh), Branch himoyasi va rulesets, Stylelint va Prettier.

1. Nega bu kerak?

Yakuniy loyiha: portfolio darsidan beri portfolio'da npm run check bor. U Prettier, html-validate va Stylelint'ni ishga tushiradi. Lekin bitta muammo bor: uni siz ishga tushirishingiz kerak. Charchadingiz, shoshdingiz, "bitta qator-ku" dedingiz — tekshiruv o'tkazib yuborildi.

Branch himoyasi darsidagi stajyorni eslang. U main ga buzuq CSS yubordi. Endi u PR orqali yuboradi — ruleset shuni talab qiladi. Lekin PR'ni kim tekshiradi? Siz kodni ko'zdan kechirasiz, lekin margin-left ning taqiqlanganini (Stylelint darsidagi qaror) eslab qolasizmi?

Yechim — tekshiruvni odamdan olib, serverga berish. Har push va har PR'da GitHub o'zi:

1. Kodni yangi, toza kompyuterga oladi.
2. Node.js va paketlarni o'rnatadi.
3. npm run check ni ishga tushiradi.
4. Natijani PR sahifasiga yozadi: yashil yoki qizil.

Hayotiy o'xshatish: shahar avtobusi. Har reysdan oldin mexanik tormoz, chiroq va g'ildiraklarni tekshiradi. Haydovchi qanchalik tajribali bo'lmasin, ko'rik har safar bo'ladi. Ko'rikdan o'tmagan avtobus yo'lga chiqmaydi. CI — kodingizning reys oldi ko'rigi.

Exit code darsida "CI'ni Git qismida sozlaymiz" degan edik. O'sha kun keldi.

2. Asosiy tushunchalar

2.1 CI va GitHub Actions

CI (Continuous Integration — uzluksiz integratsiya) — har o'zgarishni asosiy kodga qo'shishdan oldin avtomatik yig'ish va tekshirish amaliyoti. "Uzluksiz" — kuniga bir marta emas, har push'da.

GitHub Actions — GitHub ichidagi avtomatlashtirish xizmati. CI uning eng ko'p ishlatiladigan vazifasi. Saytni joylash ham shu yerda: Remote darsida ko'chirgan pages.yml — ham Actions.

Narxi (docs.github.com, 2026-yil oktabr): public repolarda GitHub'ning standart kompyuterlarida Actions bepul. Private repolarda GitHub Free tarifi oyiga 2 000 daqiqa beradi. Portfolio — public, demak bepul.

2.2 Besh so'z

Action — boshqalar yozgan tayyor qadam. Masalan, actions/checkout — "repo kodini runner'ga ol". O'zingiz yozishingiz shart emas — uses: bilan chaqirasiz. Xuddi npm paketi kabi: kimdir yozgan, siz ishlatasiz.

flowchart LR
  A["git push yoki PR"] --> B["Workflow<br/>tekshiruv.yml"]
  B --> C["Job: check<br/>runner: ubuntu"]
  C --> D["Step: checkout"]
  D --> E["Step: setup-node"]
  E --> F["Step: npm ci"]
  F --> G["Step: npm run check"]
  G --> H{"Natija"}
  H --> I["✓ yashil"]
  H --> J["X qizil"]

Nimaga qarang: hodisa workflow'ni boshlaydi, workflow ichida job, job ichida qadamlar ketma-ket. Bitta qadam yiqilsa, keyingilari bajarilmaydi va butun job qizil bo'ladi. Bu so'zlarni hozir yodlash shart emas: har biri pastdagi faylda bitta qator bo'lib uchraydi.

Runner — har safar yangi, toza virtual kompyuter. Unda sizning node_modules/ ingiz yo'q, oldingi run'dan hech narsa qolmagan. Shuning uchun har workflow kodni olishdan, Node o'rnatishdan va paketlarni o'rnatishdan boshlanadi. "Mening kompyuterimda ishlaydi" muammosi shu yerda ushlanadi.

Tekshirib ko'ring: Nega CI'da npm run check dan oldin npm ci qadami shart, kompyuteringizda esa har safar npm install yozmaysiz?

3. YAML — besh daqiqada

Workflow fayli YAML (YAML — "YAML Ain't Markup Language") formatida yoziladi. U JSON ning odam o'qishi uchun qulay ko'rinishi: qavslar o'rniga chekinish (bo'sh joylar).

# Bu izoh — # dan keyin
name: Tekshiruv          # kalit: qiymat
on:
  push:                  # ichma-ich: 2 ta bo'sh joy bilan
    branches: [main]     # qisqa ro'yxat
steps:
  - name: Kodni olish    # ro'yxat elementi: "- " bilan
    uses: actions/checkout@v7

To'rtta qoida:

1. kalit: qiymat — ikki nuqtadan keyin bo'sh joy shart.
2. Ichma-ichlik — bo'sh joylar soni bilan. Bir darajadagi kalitlar bir xil chekinishda turadi. Tab belgisi taqiqlangan — faqat bo'sh joy.
3. Ro'yxat — har element - bilan yoki qisqa [a, b] shaklida.
4. Matnni qo'shtirnoqsiz yozish mumkin: name: Node.js o'rnatish — apostrof ham muammo emas.

JSON bilan solishtiring: {"on": {"push": {"branches": ["main"]}}} — ma'nosi aynan bir xil. YAML'da chekinish qavslarning ishini qiladi. Shuning uchun bitta ortiqcha bo'sh joy ma'noni o'zgartiradi. VS Code buni rangli chiziqlar bilan ko'rsatadi.

4. Birinchi workflow

4.1 To'liq fayl

Fayl yo'li aniq shunday: .github/workflows/tekshiruv.yml. GitHub faqat shu papkadagi .yml va .yaml fayllarni workflow deb biladi.

name: Tekshiruv

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

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Kodni olish
        uses: actions/checkout@v7
      - name: Node.js o'rnatish
        uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - name: Paketlarni o'rnatish
        run: npm ci
      - name: Tekshiruv
        run: npm run check

26 qator. Endi bittalab.

4.2 name va on

name: Tekshiruv — workflow nomi. U Actions bo'limida va gh run list da ko'rinadi.

on — qaysi hodisalarda ishga tushish:

• push + branches: [main] — main ga push bo'lganda. PR merge qilinganda ham main ga commit tushadi — bu ham push.
• pull_request + branches: [main] — main ga qaratilgan PR ochilganda va unga yangi commit push qilinganda.

Nega ikkalasi? pull_request — kod main ga kirishdan oldin tekshiradi: xato PR'da ushlanadi. push — main ning o'zini tekshiradi: merge'dan keyingi holat ham toza ekaniga ishonch.

branches ni yozmasangiz, workflow hamma branchlarda ishlaydi. pages.yml dagi workflow_dispatch — qo'lda ishga tushirish (GitHub CLI darsidagi gh workflow run). Uni bu yerga ham qo'shsa bo'ladi.

4.3 permissions

Har workflow'ga GitHub vaqtinchalik kalit beradi — GITHUB_TOKEN. U bilan workflow repoga yozishi, PR'ga izoh qoldirishi mumkin. permissions: contents: read — "faqat kodni o'qishga ruxsat". Tekshiruvga boshqa hech narsa kerak emas.

Bu xavfsizlik qoidasi: har ishga faqat kerakli huquq. Agar ishlatgan action'laringizdan biri buzilgan bo'lsa ham, u repongizga hech narsa yoza olmaydi. pages.yml da esa pages: write va id-token: write bor — u saytni joylaydi, yozish huquqi kerak. Buni keyingi darsda ochamiz.

4.4 jobs va runs-on

jobs: ostida ishlar. Bizda bitta: check. Bu nom — ishning identifikatori. U keyin PR'da status check nomi bo'lib chiqadi va rulesetda aynan shu nom yoziladi. Shuning uchun uni qisqa va inglizcha qoldirdik.

runs-on: ubuntu-latest — runner turi: Linux (Ubuntu). Bizning run'larda bu Ubuntu 24.04 edi. GitHub run sahifasida ogohlantirish chiqardi: ubuntu-latest 2026-yil 19-oktabrdan Ubuntu 26 ga o'tadi. Oddiy tekshiruv uchun farqi yo'q. Windows va macOS runnerlari ham bor (windows-latest, macos-latest).

4.5 steps: uses va run

Har qadam — - bilan boshlanadigan ro'yxat elementi. name — ixtiyoriy, lekin loglarda o'qish uchun foydali. Shuning uchun nomlarni o'zbekcha yozdik.

Qadamning ikki turi:

• uses: — tayyor action. actions/checkout@v7 — "GitHub'dagi actions/checkout reposidagi action, v7 versiyasi".
• run: — terminal buyrug'i. Runner'da bash ichida bajariladi, xuddi Git Bash'dagidek.

actions/checkout@v7 — repo kodini runner'ga oladi (git clone ga o'xshash). Usiz runner bo'sh — package.json ham yo'q.

@v7 — versiya tegi (Tag va relizlar): "7-katta versiyaning eng yangisi". Biz action reposining relizlar sahifasini tekshirdik (2026-yil oktabr): checkout ning eng yangisi — v7.0.1, setup-node niki — v7.0.0. Katta versiya o'zgarsa (v7 → v8), ba'zi narsalar buzilishi mumkin. Shuning uchun faqat katta raqam yoziladi: kichik tuzatishlar o'zi keladi, buzuvchi o'zgarish esa yo'q.

actions/setup-node@v7 — runner'ga Node.js o'rnatadi. with: — action'ga beriladigan sozlamalar:

• node-version: 24 — Node 24 (kursdagi LTS — uzoq qo'llab-quvvatlanadigan versiya). Logda node: v24.21.0 chiqdi — 24 ning o'sha kundagi eng yangisi.
• cache: npm — npm keshini saqlash. Birinchi run paketlarni internetdan yuklaydi va keshni saqlaydi. Keyingilari keshdan oladi, tezroq bo'ladi. Kesh kaliti package-lock.json dan hisoblanadi: paketlar o'zgarsa, kesh yangilanadi.

npm ci — npm install ning CI uchun qat'iy varianti (ci — clean install). Farqi:

Ya'ni npm ci lock faylda yozilgan aynan o'sha versiyalarni o'rnatadi. Birinchi repo darsida package-lock.json ni commit qilishni aytgan edik — mana sababi.

npm run check — portfolio'ning o'z tekshiruvi. Biror tekshiruvchi xato topsa, buyruq noldan farqli exit code bilan tugaydi. GitHub buni ko'rib, qadamni qizil deb belgilaydi.

Tekshirib ko'ring: Kimdir cache: npm qatorini o'chirib tashladi. Tekshiruv buziladimi?

5. Push'dan oldin: lokal tekshiruv

YAML'dagi xato faqat GitHub'da, push'dan keyin bilinadi. Buni oldinroq ushlash mumkin — workflow tekshiruvchisi bilan. Biz @action-validator/cli dan foydalandik: u faylni GitHub Actions sxemasi bilan solishtiradi.

npx --yes @action-validator/cli .github/workflows/tekshiruv.yml

Hech narsa chiqmadi, exit code — 0. Fayl to'g'ri. Endi ataylab xato: runs-on o'rniga run-on:

{
  "actionType": "workflow",
  "errors": [
    {
      "code": "one_of",
      "path": "/jobs/check",
      "title": "OneOf conditions are not met",
      "states": [
        {
          "errors": [
            {
              "code": "properties",
              "detail": "Additional property 'run-on' is not allowed",
              "path": "/jobs/check",
              "title": "Property conditions are not met"
            },
            {
              "code": "required",
              "path": "/jobs/check/runs-on",
              "title": "This property is required"
            }
          ]
        },
...

Chiqish uzun, qisqartirdik. Ikki muhim qator: Additional property 'run-on' is not allowed — "run-on degan xususiyatga ruxsat yo'q", va /jobs/check/runs-on — This property is required — "bu xususiyat majburiy". Ya'ni nom xato yozilgan. path — xato qayerda: jobs → check.

VS Code'da GitHub'ning rasmiy "GitHub Actions" kengaytmasi ham shunday xatolarni yozayotganda tagiga chizib ko'rsatadi.

6. Birinchi run: yashil

6.1 PR orqali

Portfolio'ning main i himoyalangan, shuning uchun workflow ham PR orqali keladi:

git switch -c feature/ci
mkdir -p .github/workflows
code .github/workflows/tekshiruv.yml
git add .github
git commit -m "CI: npm run check workflow'ini qo'sh"
git push -u origin feature/ci
gh pr create --title "CI: npm run check workflow'ini qo'sh" \
  --body "Har push va PR'da Prettier, html-validate va Stylelint."

[feature/ci 98b500c] CI: npm run check workflow'ini qo'sh
 1 file changed, 26 insertions(+)
 create mode 100644 .github/workflows/tekshiruv.yml
...
https://github.com/login/login.github.io/pull/7

(O'rtadagi push chiqishini ... bilan qisqartirdik — GitHub CLI darsidagidek. Chiqishlarda repo nomi login/login.github.io — biz vaqtinchalik sinov reposida ishladik.)

PR ochilishi — pull_request hodisasi. Workflow shu zahoti ishga tushdi. Ajoyib joyi: workflow fayli shu PR'ning ichida — GitHub uni PR branchidan o'qiydi.

6.2 gh run watch

gh run list --limit 1
gh run watch 36818574161 --exit-status

watch qadamlarni jonli ko'rsatadi. Oxirgi ekran:

✓ feature/ci Tekshiruv login/login.github.io#7 · 36818574161
Triggered via pull_request less than a minute ago

JOBS
✓ check in 12s (ID 110228958652)
  ✓ Set up job
  ✓ Kodni olish
  ✓ Node.js o'rnatish
  ✓ Paketlarni o'rnatish
  ✓ Tekshiruv
  ✓ Post Node.js o'rnatish
  ✓ Post Kodni olish
  ✓ Complete job

ANNOTATIONS
- "The ubuntu-latest label will migrate to Ubuntu 26 beginning October 19, 2026. For more information, see https://github.com/actions/runner-images/issues/14748"
check: .github#1


✓ Run Tekshiruv (36818574161) completed with 'success'

O'zbekcha qadam nomlarimiz shu yerda. Set up job va Complete job — GitHub'ning o'z qadamlari (runner'ni tayyorlash va yopish). Post ... — action'larning yakuniy ishi: masalan, setup-node aynan shu yerda npm keshini saqlaydi. 12 soniya — butun tekshiruv.

6.3 PR'dagi natija

gh pr checks

All checks were successful
0 cancelled, 0 failing, 1 successful, 0 skipped, and 0 pending checks

   NAME                            DESCRIPTION  ELAPSED  URL
✓  Tekshiruv/check (pull_request)               12s      https://github.com/login/login.github.io...

Oldingi darsda shu buyruq no checks reported degan edi. Endi PR'da bitta tekshiruv: Tekshiruv/check — workflow nomi va job nomi, qavsda — hodisa. Brauzerda PR sahifasining pastida xuddi shu yashil belgi chiqadi.

6.4 Logni o'qish

gh run view 36818574161 --log — to'liq jurnal. Har qator: ish, qadam, vaqt (UTC) va matn. Biz eng muhim qatorlarni tanladik (qisqartirilgan):

check	Set up job	2026-10-01T05:11:18.8840991Z Image: ubuntu-24.04
check	Kodni olish	2026-10-01T05:11:20.2360851Z HEAD is now at 9967c14 Merge 98b500cf6120018aaa0041045e9a772e068da687 into 115b1003bb640c31847bcacf97b5b7fc317c6aa6
check	Node.js o'rnatish	2026-10-01T05:11:20.8657530Z node: v24.21.0
check	Node.js o'rnatish	2026-10-01T05:11:21.2445666Z npm cache is not found
check	Paketlarni o'rnatish	2026-10-01T05:11:23.4597720Z added 127 packages, and audited 128 packages in 2s
check	Tekshiruv	2026-10-01T05:11:23.6226400Z > prettier --check sayt && npm run lint && npm run lint:css
check	Tekshiruv	2026-10-01T05:11:23.8909801Z All matched files use Prettier code style!
check	Post Node.js o'rnatish	2026-10-01T05:11:26.7382338Z Cache saved with the key: node-cache-Linux-x64-npm-0b3b2f5c3eea12246a0d527b37bf32175089e2996e1045faa3c09bec0ab57d49

Uchta qiziq joy:

• HEAD is now at 9967c14 Merge 98b500c... into 115b100... — PR tekshiruvida GitHub sizning commitingizni (98b500c) emas, uning main bilan sinov birlashmasini tekshiradi. Ya'ni "PR merge bo'lsa, natija qanday bo'ladi?" degan savolga javob. Bu commit faqat runner'da bor. HEAD is now at esa HEAD va detached HEAD darsida va'da qilgan qator: CI aniq bir commitni detached holatda oladi.
• npm cache is not found — birinchi run, kesh hali yo'q. Oxirida Cache saved — saqlandi.
• added 127 packages — npm ci lock fayldagi hamma paketni o'rnatdi.

Keyingi run'da (o'sha kuni, boshqa PR'da) logda shunday chiqdi:

check	Node.js o'rnatish	2026-10-01T05:16:02.4332484Z Cache Size: ~6 MB (6432626 B)
check	Node.js o'rnatish	2026-10-01T05:16:02.4766843Z Cache restored successfully

Kesh ishladi: paketlar internetdan emas, 6 MB lik keshdan olindi.

6.5 Merge va push hodisasi

gh pr merge --squash --delete-branch
gh run list --limit 4

✓ Squashed and merged pull request login/login.github.io#7 (CI: npm run check workflow'ini qo'sh)
...
STATUS  TITLE                WORKFLOW   BRANCH      EVENT         ID           ELAPSED  AGE
✓       CI: npm run chec...  Pages      main        push          36818611303  18s      about 3 m...
✓       CI: npm run chec...  Tekshiruv  main        push          36818611288  13s      about 3 m...
✓       CI: npm run chec...  Tekshiruv  feature/ci  pull_request  36818574161  17s      about 4 m...
✓       Pages                Pages      main        workflow_...  36818467242  16s      about 5 m...

Merge main ga commit qo'shdi — bu push hodisasi. Ikkita workflow birga ishga tushdi: Tekshiruv (main ni tekshirdi) va Pages (saytni joyladi). Ular bir-birini kutmaydi — parallel ishlaydi. "Avval tekshir, keyin joyla" tartibini keyingi darsda quramiz.

7. Qizil: tekshiruv xatoni ushladi

7.1 Ataylab xato

Footer chetdan biroz ichkarida bo'lsin, deb asosiy.css ga yozdik:

footer {
  margin-left: 1rem;
}

Stylelint darsida jismoniy tomonlarni (-left, -right) taqiqlagan edik — o'rniga mantiqiy xususiyatlar. Bu qoidani unutdik deylik. Lokal npm run check ni ishga tushirmadik — to'g'ridan-to'g'ri branch, commit, push, PR:

git switch -c feature/aloqa-chegara
git commit -am "CSS: footer'ga chap chekinish qo'sh"
git push -u origin feature/aloqa-chegara
gh pr create --title "CSS: footer'ga chap chekinish qo'sh" \
  --body "Footer chetdan biroz ichkarida."

PR #8 ochildi.

7.2 Natija

gh run watch 36818894878 --exit-status

X feature/aloqa-chegara Tekshiruv login/login.github.io#8 · 36818894878
Triggered via pull_request less than a minute ago

JOBS
X check in 10s (ID 110229942686)
  ✓ Set up job
  ✓ Kodni olish
  ✓ Node.js o'rnatish
  ✓ Paketlarni o'rnatish
  X Tekshiruv
  - Post Node.js o'rnatish
  ✓ Post Kodni olish
  ✓ Complete job

ANNOTATIONS
X Process completed with exit code 2.
check: .github#25

- "The ubuntu-latest label will migrate to Ubuntu 26 beginning October 19, 2026. For more information, see https://github.com/actions/runner-images/issues/14748"
check: .github#1


X Run Tekshiruv (36818894878) completed with 'failure'

• X Tekshiruv — bizning qadam yiqildi. Undan oldingilari yashil: kod olindi, Node va paketlar o'rnatildi.
• - Post Node.js o'rnatish — - "o'tkazib yuborildi" degani: xato bo'lgani uchun kesh saqlanmadi.
• Process completed with exit code 2. — tarjimasi: "jarayon 2 exit code bilan tugadi". Noldan farqli kod — xato (Exit code darsi). Stylelint xato topsa, 2 qaytaradi.

PR'da:

gh pr checks

Some checks were not successful
0 cancelled, 1 failing, 0 successful, 0 skipped, and 0 pending checks

   NAME                            DESCRIPTION  ELAPSED  URL
X  Tekshiruv/check (pull_request)               10s      https://github.com/login/login.github.io...

7.3 Nega yiqildi: --log-failed

Butun log kerak emas — faqat yiqilgan qadam:

gh run view 36818894878 --log-failed

check	Tekshiruv	2026-10-01T05:15:34.0993310Z ##[group]Run npm run check
...
check	Tekshiruv	2026-10-01T05:15:34.4585365Z All matched files use Prettier code style!
...
check	Tekshiruv	2026-10-01T05:15:35.0490312Z > stylelint "sayt/**/*.css"
check	Tekshiruv	2026-10-01T05:15:35.6065910Z sayt/assets/css/asosiy.css
check	Tekshiruv	2026-10-01T05:15:35.6067180Z   23:3  ✖  Disallowed property "margin-left"  property-disallowed-list
check	Tekshiruv	2026-10-01T05:15:35.6068013Z ✖ 1 problem (1 error, 0 warnings)
check	Tekshiruv	2026-10-01T05:15:35.6325408Z ##[error]Process completed with exit code 2.

Bo'sh va takroriy qatorlarni ... bilan qisqartirdik. Xom logda rang kodlari ham bor (^[[31m kabi belgilar) — ularni olib tashladik. Xabar tanish: Disallowed property "margin-left" — "margin-left xususiyatiga ruxsat yo'q", 23-qator, 3-ustun. Prettier va html-validate o'tdi, Stylelint ushladi. Kompyuteringizdagi npm run check aynan shu xabarni berardi — CI uni siz unutganda ham ishga tushirdi.

8. Status checkni majburiy qilish

8.1 Hozircha qizil PR ham merge bo'ladi

Qizil belgi — ogohlantirish, xolos. Rulesetda "tekshiruv o'tishi shart" degan qoida yo'q. Ya'ni PR #8 ni hozir ham merge qilsa bo'lardi — buzuq CSS main ga va saytga tushardi.

Branch himoyasi darsida bu qoidani "CI darsida qo'shamiz" degan edik.

8.2 Rulesetga check qo'shish

Settings → Rules → Rulesets → main himoyasi:

1. Require status checks to pass ni belgilang.
2. Qo'shimcha sozlamalarda ("Additional settings") tekshiruv nomini yozing — check — va uni GitHub Actions'dan kelgan natija sifatida tanlab, + tugmasi bilan qo'shing.
3. Require branches to be up to date before merging — belgilamang (yumshoq, "loose" rejim).
4. Save changes.

Nega aynan check? GitHub hujjatiga ko'ra, workflow tekshiruvining nomi — job nomi. Workflow nomi (Tekshiruv) va hodisa (pull_request) hisobga olinmaydi. Job nomini o'zgartirsangiz (masalan check → tekshir), rulesetni ham yangilash kerak. Aks holda ruleset hech qachon kelmaydigan tekshiruvni kutib qoladi va hamma PR bloklanadi.

Nega loose? Qattiq ("strict") rejimda PR branchi main ning eng oxirgi holatini o'z ichiga olishi shart. Yolg'iz ishlaganda bu har merge'dan keyin keyingi PR'ni yangilashga majbur qiladi. Ozgina foyda, ko'p ovoragarchilik. Katta jamoada esa strict foydali.

JSON shaklida (yangi qism — rulesetdagi beshinchi qoida):

{
  "type": "required_status_checks",
  "parameters": {
    "strict_required_status_checks_policy": false,
    "required_status_checks": [
      { "context": "check", "integration_id": 15368 }
    ]
  }
}

context: "check" — tekshiruv nomi, strict_...: false — loose rejim. integration_id: 15368 — "bu natija faqat GitHub Actions'dan kelsin". Uni formadagi tanlov o'zi qo'yadi. Biz rulesetni GitHub CLI darsidagi gh api --method PUT bilan yangiladik, javobdagi qoidalar ro'yxati:

[
  "deletion",
  "non_fast_forward",
  "required_linear_history",
  "pull_request",
  "required_status_checks"
]

8.3 Endi qizil PR to'xtaydi

gh pr merge --squash

X Pull request login/login.github.io#8 is not mergeable: the base branch policy prohibits the merge.
To have the pull request merged after all the requirements have been met, add the `--auto` flag.
To use administrator privileges to immediately merge the pull request, add the `--admin` flag.

Tanish xabar (GitHub CLI darsida tasdiq yo'qligi uchun chiqqan edi). Bu safar sababi — qizil check. Brauzerda ham merge tugmasi bloklanadi.

8.4 Tuzatish

margin-left → margin-inline-start (chap tomon o'rniga "qator boshi" — Mantiqiy xususiyatlar darsidan). Shu branch'da yangi commit:

git commit -am "CSS: chekinishni mantiqiy xususiyatga o'tkaz"
git push

[feature/aloqa-chegara 3d92e76] CSS: chekinishni mantiqiy xususiyatga o'tkaz
 1 file changed, 1 insertion(+), 1 deletion(-)
To https://github.com/login/login.github.io.git
   bf5291c..3d92e76  feature/aloqa-chegara -> feature/aloqa-chegara

PR'ga yangi commit — yangi pull_request run. U yashil bo'ldi (✓ check in 8s). Keyin:

gh pr checks
gh pr merge --squash --delete-branch
git log --oneline -4

All checks were successful
0 cancelled, 0 failing, 1 successful, 0 skipped, and 0 pending checks

   NAME                            DESCRIPTION  ELAPSED  URL
✓  Tekshiruv/check (pull_request)               8s       https://github.com/login/login.github.io...
✓ Squashed and merged pull request login/login.github.io#8 (CSS: footer'ga chap chekinish qo'sh)
...
da02a02 (HEAD -> main, origin/main, origin/HEAD) CSS: footer'ga chap chekinish qo'sh (#8)
6316d3a CI: npm run check workflow'ini qo'sh (#7)
115b100 Loyihalar: Bahor kartasini qo'sh (#6)
a2a3d58 Aloqa: Telegram havolasini qo'sh (#4)

Squash ikki commitni (xato va tuzatish) bitta qilib qo'shdi: main tarixida xato hech qachon bo'lmagan. Butun yo'l:

flowchart TD
  A["PR #8 ochildi"] --> B["check: X qizil"]
  B --> C{"Ruleset:<br/>check majburiy"}
  C -- "merge" --> D["Rad etildi"]
  D --> E["Tuzatish commiti<br/>git push"]
  E --> F["check: ✓ yashil"]
  F --> G["Squash and merge"]

Nimaga qarang: tuzatish yangi PR emas — o'sha PR'ga yangi commit. Har push tekshiruvni qayta ishga tushiradi va natija PR'ga yoziladi.

Tekshirib ko'ring: Rulesetda check majburiy. Siz workflow faylidagi job nomini check dan tekshir ga o'zgartirib, PR ochdingiz. Nima bo'ladi?

9. Hujumchi nigohi

GitHub asoslari darsida aytgan edik: public repoda Actions loglari ham hammaga ochiq. Yuqorida o'qigan har bir log qatorini istalgan odam o'qiy oladi. Hujumchi shu yerda ikki narsani qidiradi.

1. Logdagi sir. Workflow'ga parol yoki token kerak bo'lsa (masalan, boshqa serverga joylash uchun), uni YAML faylga yozmaysiz — fayl repoda, hammaga ko'rinadi. GitHub buning uchun secrets (maxfiy qiymatlar) bo'limini beradi: Settings → Secrets and variables → Actions. Workflow ichida unga ${{ secrets.NOMI }} deb murojaat qilinadi (${{ }} belgisini keyingi darsda ochamiz). GitHub hujjatiga ko'ra:

• secret logga tushib qolsa, GitHub uni *** bilan yashiradi;
• lekin bu himoya to'liq emas: qiymat o'zgartirilib (masalan, qismlarga bo'linib) chiqarilsa, yashirilmasligi mumkin. Shuning uchun secret'ni hech qachon echo qilmang;
• boshqa odamning forkidan kelgan PR'da secret'lar workflow'ga umuman berilmaydi — begona kod ularni o'g'irlay olmaydi.

Bizning tekshiruv.yml ga sir kerak emas — eng xavfsiz holat shu.

2. Begona action. actions/checkout@v7 — boshqalar yozgan kod, u sizning runner'ingizda ishlaydi. v7 — tag, tagni esa egasi boshqa commitga ko'chirishi mumkin. Agar action egasining akkaunti buzilsa, xuddi shu v7 ostida zararli kod paydo bo'lishi mumkin. GitHub hujjati himoyani shunday beradi: faqat ishonchli action'lar (masalan, actions/ — GitHub'ning o'zi) va eng kam huquq — bizdagi permissions: contents: read. Juda muhim loyihalarda action tag bilan emas, to'liq commit SHA'si bilan yoziladi — SHA'ni hech kim o'zgartira olmaydi (Git ichkaridan).

10. Ko'p uchraydigan xatolar

10.1 Workflow umuman ishga tushmadi

Sabablari:

• Papka nomi xato: .github/workflow/ (s siz) yoki github/workflows/ (nuqtasiz). To'g'risi — .github/workflows/.
• branches: [main], lekin push boshqa branch'ga. push filtri faqat main ni ushlaydi — PR ochmaguningizcha branch tekshirilmaydi.
• YAML xato — GitHub Actions bo'limida workflow nomi o'rnida xato xabari chiqadi. Lokal tekshiruvchi buni oldinroq ushlaydi.

10.2 Tab belgisi

YAML'da tab taqiqlangan. VS Code'da .yml fayl ochiq bo'lsa, o'ng pastki burchakda "Spaces: 2" ko'rinsin. "Tab Size" chiqsa — bosing va "Indent Using Spaces" ni tanlang.

10.3 npm ci lock faylsiz

package-lock.json commit qilinmagan bo'lsa, npm ci qadami yiqiladi:

npm error code EUSAGE
npm error
npm error The `npm ci` command can only install with an existing package-lock.json or
npm error npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm error later to generate a package-lock.json file, then try again.

Tarjimasi: "npm ci faqat mavjud package-lock.json bilan o'rnata oladi". Lokal npm install qiling va package-lock.json ni commit qiling. Uni .gitignore ga yozmang.

10.4 CI'da yashil, kompyuterda qizil

Bizda shunday bo'ldi. .gitattributes yo'q sinov reposida, Windows'da npm run check:

Checking formatting...
[warn] sayt/loyihalar/index.html
[warn] Code style issues found in the above file. Run Prettier with --write to fix.

CI'da esa o'sha fayl o'tdi. Sababi — qator oxirlari: Git Windows'da faylni CRLF bilan chiqardi, Prettier esa LF kutadi. Linux runner'da fayl LF bilan. Yechim .gitattributes darsida: * text=auto eol=lf. Portfolio'ingizda u allaqachon bor — shuning uchun sizda bu xato chiqmasligi kerak.

10.5 Ruleset check ni topmayapti

Ruleset formasi tekshiruv nomlarini repoda avval ishlagan tekshiruvlardan taklif qiladi. Workflow hali bir marta ham ishlamagan bo'lsa, check ro'yxatda bo'lmaydi. Avval workflow'ni PR orqali qo'shing va bir marta ishlating, keyin rulesetga qo'shing. Biz ham shu tartibda qildik.

11. Mashqlar

Javoblarni mashqlar reposida 07/35-github-actions/javoblar.md ga yozib, 07/35: CI mashqlari javoblarini qo'sh bilan commit qiling.

1-mashq (oson): Kim nima?

Moslang: on, runs-on, uses, run, jobs.

1. Workflow qachon ishga tushadi.
2. Qaysi kompyuterda.
3. Tayyor action'ni chaqirish.
4. Terminal buyrug'i.
5. Ishlar ro'yxati.

2-mashq (o'rta): Bo'sh joylarni to'ldiring

landing uchun workflow — faqat PR'larda ishlasin:

name: Tekshiruv

on:
  [___:pull_request]:
    branches: [main]

jobs:
  check:
    runs-on: [___:ubuntu-latest]
    steps:
      - uses: actions/@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm [___:ci]
      - run: npm run check

Ishora: «Birinchi workflow» bo'limidagi to'liq faylni solishtiring.

3-mashq (qiyin): Uchta xato

Stajyorning workflow'i GitHub'da ishga tushmayapti. Fayl .github/workflow/ci.yml da:

name: CI
on:
  push:
    branches: [main]
jobs:
  check:
    steps:
      - uses: actions/checkout@v7
      - run: npm run check

Uchta muammoni toping va tuzating.

Ishora: «Ko'p uchraydigan xatolar» bo'limi va CI runner'i har safar yangi kompyuter ekani («Asosiy tushunchalar» bo'limi).

4-mashq: Portfolio qadami — CI va majburiy tekshiruv

1. feature/ci branchida .github/workflows/tekshiruv.yml ni yarating (to'liq fayl — «Birinchi workflow» bo'limida).
2. npx --yes @action-validator/cli .github/workflows/tekshiruv.yml — xatosiz.
3. Commit (CI: npm run check workflow'ini qo'sh), push, gh pr create.
4. gh run watch — yashil bo'lguncha kuting. gh pr checks nima deydi?
5. Merge qiling. gh run list da Tekshiruv va Pages ikkalasi main da ishladimi?
6. Rulesetga check ni majburiy status check qilib qo'shing (loose).
7. Sinov: yangi branch'da CSS'ga padding-right: 1rem qo'shing, PR oching. Qizil bo'ldimi? Merge bloklandimi? Tuzating (padding-inline-end) va merge qiling.

landing reposida ham 1–6 qadamlar.

git switch -c feature/padding-sinov
# asosiy.css oxiriga: footer { padding-right: 1rem; }
git commit -am "CSS: footer'ga o'ng chekinish qo'sh"
git push -u origin feature/padding-sinov
gh pr create --fill
gh pr checks
gh pr merge --squash

# padding-right → padding-inline-end
git commit -am "CSS: chekinishni mantiqiy xususiyatga o'tkaz"
git push
gh pr checks
gh pr merge --squash --delete-branch

12. Real ishda

• Har jiddiy loyihada CI bor. Frontend'da odatda: lint, format tekshiruvi, type-check, testlar, build. Bugun siz birinchi uchtasini qildingiz. Qolganlari JavaScript, TypeScript va test qismlarida qo'shiladi.
• "Qizil main" — favqulodda holat. Jamoada main qizil bo'lsa, hamma o'z ishini to'xtatib, avval uni tuzatadi.
• Pipeline — lint → test → build → deploy zanjiri. Uni CI/CD tushunchasi darsida to'liq quramiz. Deploy qismining birinchi namunasi — keyingi dars.
• Intervyuda: "CI nima va nega kerak?", "npm ci va npm install farqi?", "Workflow, job va step farqi?", "Status check'ni qanday majburiy qilasiz?"

Xulosa

• CI — har push va PR'da kodni serverda avtomatik tekshirish; GitHub Actions — GitHub'ning shu xizmati, public repoda bepul.
• Workflow — .github/workflows/*.yml; on (hodisa) → jobs → runs-on (runner) → steps (uses yoki run).
• YAML: kalit: qiymat, chekinish faqat bo'sh joy bilan, ro'yxat - bilan.
• Standart qadamlar: actions/checkout@v7, actions/setup-node@v7 (node-version: 24, cache: npm), npm ci, npm run check.
• Natija PR'da yoki X; gh run watch, gh pr checks, gh run view --log-failed bilan o'qiladi.
• Rulesetda status check check (job nomi) majburiy — qizil PR merge bo'lmaydi.
• Public repoda loglar ochiq: sir — faqat secrets da, hech qachon echo qilinmaydi; workflow huquqi — eng kami.

Keyingi dars: GitHub Pages'ga git va Actions orqali avtomatik deploy — pages.yml ni ochamiz, deploy'dan oldin tekshiruvni qo'shamiz va portfolio bilan landing'ni avtomatik joylashni yakunlaymiz.

Manbalar

• GitHub Docs: "Understanding GitHub Actions", "Workflow syntax for GitHub Actions", "Events that trigger workflows" — docs.github.com/actions
• GitHub Docs: "GitHub Actions billing", "Troubleshooting rules" (required status checks) — docs.github.com
• GitHub Docs: "Using secrets in GitHub Actions", "Security hardening for GitHub Actions" — docs.github.com/actions
• actions/checkout va actions/setup-node relizlari va README — github.com/actions
• npm hujjati: "npm ci" — docs.npmjs.com