IlmHamroh
JavaScript Full-stack/7-qism. Git va GitHub asoslari36/36-dars22 daqiqa
Mundarija (43)

GitHub Pages'ga avtomatik deploy: git push'dan saytgacha — 07-qism yakuniy loyihasi

Qisqacha: GitHub Pages saytni ikki yo'l bilan joylaydi: branch'dan yoki GitHub Actions workflow'idan. Actions yo'lida pages.yml saytni upload-pages-artifact bilan yuklaydi va deploy-pages bilan joylaydi. Workflow'ga check ishini qo'shib, deploy ga needs: check yozsangiz, tekshiruvdan o'tmagan kod saytga hech qachon chiqmaydi. Custom domen Settings → Pages'da ulanadi (Actions yo'lida CNAME fayl kerak emas), HTTPS bepul. Bu dars — 07-qism yakuniy loyihasi: portfolio va landing git push bilan o'zi yangilanadi.

Bu darsda

  • Pages'ning ikki manbasini (branch va Actions) farqlay olasiz va pages.yml ning har qatorini tushuntirasiz.
  • Deploy'dan oldin npm run check ni qo'shasiz: needs, ish darajasidagi permissions.
  • github-pages muhiti (environment) faqat main ga joylashga ruxsat berishini ko'rasiz.
  • Custom domen, CNAME, DNS yozuvlari va HTTPS qanday ishlashini bilasiz.
  • 404 sahifa va loyiha saytidagi yo'l tuzog'ini tushunasiz.
  • Portfolio va landing'ni to'liq avtomatik deploy'ga o'tkazasiz — qism yakuniy loyihasi.

Oldin bilishingiz kerak: GitHub Actions: birinchi CI workflow, Remote: clone, fetch, pull, push, Birinchi deploy.

1. Nega bu kerak?

Birinchi deploy darsida portfolio'ni brauzer orqali yukladingiz: fayllarni sudrab tashlash, Commit changes. Har o'zgarishda — yana. Remote darsida bu o'zgardi: pages.yml ko'chirildi, endi git push saytni o'zi yangilaydi. Oldingi darsda esa har PR'ga avtomatik tekshiruv qo'shildi.

Lekin hali bitta teshik bor. main ga push bo'lganda ikki workflow parallel ishlaydi: Tekshiruv va Pages. Ular bir-birini kutmaydi. Ruleset buzuq kodni main ga kiritmaydi — lekin agar kimdir rulesetni vaqtincha o'chirib qo'ysa-chi? Yoki pages.yml ni qo'lda, buzuq branch'dan ishga tushirsa-chi? Sayt baribir joylanadi.

Bugun zanjirni yopamiz: avval tekshir, keyin joyla. Tekshiruv yiqilsa, sayt eski holatda qoladi — buzuq versiya internetga chiqmaydi.

Hayotiy o'xshatish: «Bahor» oshxonasi. Rustam aka oshni damlaydi, Jasur aka tatib ko'radi. Faqat shundan keyin Otabek uni mehmon stoliga olib chiqadi. Tuz ko'p bo'lsa, osh oshxonadan chiqmaydi. check — tatib ko'rish, deploy — stolga olib chiqish, needs — "tatib ko'rilmaguncha olib chiqma" qoidasi.

2. Pages manbasi: branch yoki Actions

2.1 Ikki yo'l

Settings → Pages → "Build and deployment" → Source da ikki variant bor:

Deploy from a branch GitHub Actions
Nima joylanadi Branch'dagi papka (/ yoki /docs) Workflow yuklagan istalgan papka
Tekshiruv Yo'q Workflow ichida, xohlagancha
Build (yig'ish) Faqat Jekyll Istalgan vosita (masalan Vite)
Kursda Birinchi deploy, landing (shu darsgacha) Portfolio (Remote darsidan), shu darsdan landing ham

Portfolio'da fayllar sayt/ ichida, ildizda esa package.json va sozlamalar. Branch yo'li faqat ildiz yoki /docs ni beradi. Shuning uchun Remote darsida Actions yo'liga o'tgan edik: path: sayt — "faqat sayt/ ni joyla".

2.2 pages.yml qatorma-qator

Bu fayl Remote darsida ko'chirildi va "qatorlarini keyin ochamiz" degan edik. Endi CI darsidan keyin uning ko'p qismi tanish:

yaml
name: Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/configure-pages@v6
      - uses: actions/upload-pages-artifact@v5
        with:
          path: sayt
      - id: deployment
        uses: actions/deploy-pages@v5

Yangi qatorlar:

  • permissions — pages: write (saytni joylash huquqi) va id-token: write (GitHub Pages'ga "men shu reponing workflow'iman" deb isbotlovchi bir martalik kalit olish).
  • concurrency: group: pages — bir vaqtda faqat bitta deploy. Ketma-ket ikki push bo'lsa, ikkinchisi birinchisini kutadi. cancel-in-progress: false — boshlangan deploy'ni to'xtatma: yarim joylangan sayt bo'lmasin.
  • environment: github-pages — muhit (environment): kod joylanadigan manzil, bu yerda — sayt. (Muhit o'zgaruvchilari bilan adashtirmang — nomi o'xshash, ma'nosi boshqa.) Pages manbasi Actions'ga o'tganda GitHub uni o'zi yaratadi. Uning qoidasi bor — pastda sinab ko'ramiz.
  • url: ${{ ... }} — ${{ }} — workflow ichidagi ifoda. steps.deployment.outputs.page_url — "deployment id'li qadam qaytargan sayt manzili". Shu manzil Actions sahifasida havola bo'lib chiqadi.
  • configure-pages — Pages sozlamalarini o'qiydi va keyingi qadamlarga beradi.
  • upload-pages-artifact — sayt/ papkasini arxivlab, artefakt sifatida yuklaydi. Artefakt — workflow ishlab chiqargan va saqlab qo'ygan fayl.
  • deploy-pages — o'sha artefaktni saytga joylaydi. id: deployment — natijasiga murojaat qilish uchun nom.

Versiyalar (2026-yil oktabr, relizlar sahifasidan): checkout@v7, configure-pages@v6, upload-pages-artifact@v5, deploy-pages@v5, setup-node@v7.

Deploy logidagi eng muhim qatorlar (GitHub CLI darsidagi gh run view --log dan, qisqartirilgan):

text
deploy	Run actions/upload-pages-artifact@v5	2026-10-01T05:10:00.4592009Z Artifact github-pages has been successfully uploaded! Final size is 1213 bytes. Artifact ID is 11142780849
deploy	Run actions/deploy-pages@v5	2026-10-01T05:10:06.6641029Z Reported success!
deploy	Complete job	2026-10-01T05:10:06.9317386Z Evaluated environment url: https://login.github.io/

Chiqishlarda sayt manzilini https://login.github.io/ ga, repo nomini login/login.github.io ga almashtirdik. Biz vaqtinchalik sinov reposida ishladik.

Tekshirib ko'ring: Nega upload-pages-artifact da path: sayt yozilgan, butun repo emas?

Javob

Internetga faqat sayt fayllari chiqishi kerak. Butun repo yuklansa, package.json, .stylelintrc.json va boshqa sozlamalar ham hammaga ochiq bo'lardi (Birinchi deploy darsidagi «Hujumchi nigohi»). sayt/ esa saytning ildizi bo'ladi: sayt/index.html → https://login.github.io/.

3. Avval tekshir, keyin joyla

3.1 Ikki ish va needs

Remote darsidagi fayl — boshlang'ich, minimal versiya edi: bitta deploy ishi. Endi uni kengaytiramiz. Quyidagi fayl — 07-qismning yakuniy pages.yml i: portfolio ham, landing ham aynan shu fayl bilan ishlaydi.

yaml
name: Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: pages
  cancel-in-progress: false

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

  deploy:
    needs: check
    permissions:
      contents: read
      pages: write
      id-token: write
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/configure-pages@v6
      - uses: actions/upload-pages-artifact@v5
        with:
          path: sayt
      - id: deployment
        uses: actions/deploy-pages@v5

Uchta o'zgarish:

  1. Yangi check ishi — CI darsidagi qadamlarning o'zi. Har ish o'z runner'ida ishlaydi, shuning uchun checkout ikkala ishda ham bor.
  2. needs: check — "deploy faqat check muvaffaqiyatli tugagandan keyin boshlansin". needs yo'q bo'lsa, ishlar parallel ketadi.
  3. permissions ishga ko'chdi. Yuqorida faqat contents: read qoldi. Yozish huquqi faqat deploy da. Ish darajasidagi permissions yuqoridagini to'liq almashtiradi, shuning uchun contents: read u yerda qayta yozilgan. Natija: npm ci o'rnatgan begona paketlar ishlaydigan check ishida saytga yozish huquqi yo'q.
flowchart LR
  A["git push main"] --> B["check<br/>npm ci, npm run check"]
  B -- "✓" --> C["deploy<br/>upload, deploy-pages"]
  B -- "X" --> D["deploy o'tkazib<br/>yuboriladi"]
  C --> E["login.github.io<br/>yangilandi"]
  D --> F["Sayt eski holatda<br/>qoladi"]

Nimaga qarang: qizil yo'l saytga yetib bormaydi. Eng yomon holatda sayt yangilanmaydi — lekin hech qachon buzilmaydi.

3.2 Haqiqiy run

O'zgarish PR orqali keldi (main himoyalangan): Tekshiruv yashil, squash merge, main ga push. Keyin:

bash
gh run watch 36819531003 --exit-status
text
✓ main Pages · 36819531003
Triggered via push less than a minute ago

JOBS
✓ check in 16s (ID 110231887722)
  ✓ Set up job
  ✓ Run actions/checkout@v7
  ✓ Run actions/setup-node@v7
  ✓ Run npm ci
  ✓ Run npm run check
  ✓ Post Run actions/setup-node@v7
  ✓ Post Run actions/checkout@v7
  ✓ Complete job
✓ deploy in 16s (ID 110231960192)
  ✓ Set up job
  ✓ Run actions/checkout@v7
  ✓ Run actions/configure-pages@v6
  ✓ Run actions/upload-pages-artifact@v5
  ✓ Run actions/deploy-pages@v5
  ✓ Post Run actions/checkout@v7
  ✓ 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 Pages (36819531003) completed with 'success'

watch ning oraliq ekranlarida tartib aniq ko'rindi: check tugaguncha deploy ro'yxatda faqat * deploy bo'lib turdi, qadamlarsiz. U check dan keyin boshlandi. Qadam nomlari bu safar inglizcha (Run npm ci): pages.yml da qadamlarga name bermadik va GitHub ularni buyruqdan o'zi nomladi.

3.3 Sayt tekshiruvi

bash
K='%{http_code}\n'
S=https://login.github.io
curl -s -o /dev/null -w "$K" $S/
curl -s -o /dev/null -w "$K" $S/package.json
curl -s -o /dev/null -w "$K" $S/sayt/
text
200
404
404

K va S — qisqa yozish uchun shell o'zgaruvchilari (Muhit o'zgaruvchilari darsi). curl (HTTP metodlari darsidan) bu yerda faqat javob kodini chiqaradi. Bosh sahifa — 200. package.json va /sayt/ — 404: sozlamalar internetda yo'q, sayt/ esa saytning ildiziga aylangan. Oldingi darsdagi footer tuzatishi ham joyida:

bash
curl -s https://login.github.io/assets/css/asosiy.css | tail -4
text

footer {
  margin-inline-start: 1rem;
}

3.4 Qizil holat: deploy o'tkazib yuboriladi

main ga buzuq kod ruleset tufayli kirmaydi. Shuning uchun darvozani boshqa yo'l bilan sinadik. Buzuq branch ochdik (padding-left — Stylelint taqiqlagan) va pages.yml ni qo'lda o'sha branch'dan ishga tushirdik:

bash
gh workflow run pages.yml --ref feature/buzuq-sinov
gh run view 36819603186
text
X feature/buzuq-sinov Pages · 36819603186
Triggered via workflow_dispatch about 1 minute ago

JOBS
X check in 9s (ID 110232111259)
  ✓ Set up job
  ✓ Run actions/checkout@v7
  ✓ Run actions/setup-node@v7
  ✓ Run npm ci
  X Run npm run check
  - Post Run actions/setup-node@v7
  ✓ Post Run actions/checkout@v7
  ✓ Complete job
- deploy in 0s (ID 110232158763)
...

- deploy in 0s — - "o'tkazib yuborildi". check yiqildi, needs deploy ni boshlatmadi. Sayt bir soniya ham buzuq bo'lmadi. (--ref — workflow qaysi branch'dan ishga tushishi; gh workflow run ni GitHub CLI darsida ko'rgansiz.)

3.5 Muhit himoyasi: faqat main

Endi aksincha: toza branch'dan qo'lda deploy. Tekshiruv o'tadi — sayt yangilanadimi?

bash
gh workflow run pages.yml --ref feature/muhit-sinov
gh run view 36819631447
text
X feature/muhit-sinov Pages · 36819631447
Triggered via workflow_dispatch less than a minute ago

JOBS
✓ check in 7s (ID 110232202698)
X deploy in 2s (ID 110232240634)

ANNOTATIONS
...
X Branch "feature/muhit-sinov" is not allowed to deploy to github-pages due to environment protection rules.
deploy: .github#1

X The deployment was rejected or didn't satisfy other protection rules.
deploy: .github#1

Tarjimasi: "feature/muhit-sinov branchiga github-pages muhitiga joylashga muhit himoyasi qoidalari ruxsat bermaydi". Bu — github-pages muhitining standart qoidasi: joylash faqat main dan. Biz sinov reposida tekshirdik: Settings → Environments → github-pages da ruxsat etilgan branch sifatida faqat main turibdi.

Uch himoya qatlami bir-birini to'ldiradi:

  • needs: check — tekshiruvdan o'tmagan kod joylanmaydi.
  • Muhit himoyasi — main dan boshqa branch joylanmaydi.
  • Ruleset (Branch himoyasi, CI) — main ga faqat yashil PR orqali.

Tekshirib ko'ring: Nega check ishida pages: write huquqi yo'q? Axir u ham shu workflow'ning ishi.

Javob

check ishi npm ci bilan 127 ta begona paketni o'rnatadi va ishga tushiradi. Ulardan biri buzilgan (zararli) bo'lsa, u ishning huquqlaridan foydalanishi mumkin. Huquq faqat kerak joyda: check faqat o'qiydi, saytga yozish faqat deploy da. Bu "eng kam huquq" tamoyili.

4. Custom domen va HTTPS

4.1 Nega va qanday

login.github.io — bepul va ishonchli. Lekin ba'zan o'z domeningiz kerak: masalan example.com (namuna sifatida — siz sotib olgan domenni yozasiz). Domen pullik — bir yillik ijara. Bu qadam ixtiyoriy: portfolio login.github.io da ham to'liq ishlaydi.

Ulash ikki tomonda bo'ladi (docs.github.com, "Managing a custom domain"):

  1. GitHub'da: Settings → Pages → "Custom domain" ga domenni yozasiz → Save.
  2. Domen sotuvchisi (DNS provayder) sahifasida: domenni GitHub serverlariga yo'naltiruvchi yozuvlar qo'shasiz.

DNS — internetning "telefon kitobi": domen nomini server manziliga (IP) aylantiradi (Domen va DNS darsidan tanish). Yozuv turlari:

Domen Yozuv Qiymati
www.example.com (subdomen) CNAME login.github.io
example.com (apex — asosiy) A 4 ta IP (pastda)
example.com (IPv6) AAAA 4 ta IPv6 manzil

Apex — domenning o'zi, oldida www. siz. IPv6 — IP manzilning yangi, uzunroq turi; AAAA yozuvi ixtiyoriy — GitHub hujjatiga ko'ra, xohlasangiz A yozuvlariga qo'shimcha qilasiz.

GitHub Pages'ning A yozuvlari uchun IP manzillari (hujjatdan):

text
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

CNAME yozuvi doim login.github.io ga qaraydi — repo nomisiz.

4.2 CNAME fayli — Actions yo'lida kerak emas

Eski darsliklarda "repo ildiziga CNAME faylini qo'shing" deyiladi. Bu branch manbasi uchun to'g'ri: GitHub o'zi shu faylni commit qiladi. GitHub hujjatiga ko'ra, Actions workflow'i bilan joylaganda CNAME fayl yaratilmaydi, mavjudi e'tiborga olinmaydi va u kerak emas. Domen faqat Settings → Pages'da saqlanadi.

Sinov reposimizda domen ulanmagan — Pages API shuni ko'rsatadi:

bash
gh api "repos/{owner}/{repo}/pages" \
  --jq '{html_url, build_type, https_enforced, cname}'
text
{
  "build_type": "workflow",
  "cname": null,
  "html_url": "https://login.github.io/",
  "https_enforced": true
}

build_type: workflow — manba Actions. cname: null — custom domen yo'q. https_enforced: true — HTTPS majburiy.

4.3 HTTPS va domen tasdig'i

HTTPS — shifrlangan ulanish (HTTPS va TLS darsi). github.io manzillarida u doim yoqilgan. Custom domenda GitHub sertifikatni o'zi bepul oladi. Keyin Enforce HTTPS katagini yoqasiz. GitHub hujjatiga ko'ra, bu katak paydo bo'lishiga 24 soatgacha ketishi mumkin.

Domen tasdig'i (verification) — xavfsizlik qadami. Siz repo'ni o'chirsangiz yoki Pages'ni o'chirsangiz, DNS esa hali GitHub'ga qarab tursa, boshqa odam o'z reposida sizning domeningizni ulab olishi mumkin. Hujjatda buni "domain takeover" (domenni egallab olish) deyiladi. Profil sozlamalarida domenni tasdiqlasangiz, uni faqat sizning repolaringiz ishlata oladi.

4.4 Pages qoidalari va chegaralari

GitHub hujjatidan (2026-yil oktabr):

  • Joylangan sayt — 1 GB gacha. Deploy 10 daqiqadan oshsa, to'xtatiladi.
  • Oyiga 100 GB trafik — "yumshoq" chegara.
  • Pages onlayn biznes, internet-do'kon yoki pullik xizmat (SaaS) uchun emas. Portfolio, hujjat, loyiha sahifasi, choyxona haqida ma'lumot beruvchi landing — mos.
  • Parol va maxfiy ma'lumotni Pages'ga qo'ymang — sayt hammaga ochiq.

5. 404 sahifa va loyiha saytidagi yo'l tuzog'i

5.1 404.html

Mavjud bo'lmagan manzilga kirilsa, Pages saytdagi 404.html ni ko'rsatadi va 404 kodini qaytaradi. Portfolio'da u Yakuniy loyiha: portfolio dan beri bor.

5.2 Foydalanuvchi sayti va loyiha sayti

Ikki xil Pages manzili bor:

  • Foydalanuvchi sayti — login.github.io reposidan: https://login.github.io/. Sayt domen ildizida.
  • Loyiha sayti — boshqa har qanday repodan: https://login.github.io/landing/. Sayt papkada yashaydi.

Farq / bilan boshlanadigan yo'llarda chiqadi. Bizning sinov reposimiz aynan loyiha sayti edi va biz tuzoqqa haqiqatan tushdik. 404 sahifasida CSS shunday ulangan:

bash
curl -s https://login.github.io/sinov-repo/yoq-sahifa \
  | grep stylesheet
text
    <link rel="stylesheet" href="/assets/css/asosiy.css" />

/assets/... — domen ildizidan. Loyiha saytida bu manzil https://login.github.io/assets/css/asosiy.css bo'ladi — u yerda fayl yo'q:

text
404

Ya'ni 404 sahifa CSS'siz ochildi. Bu yerda sinov reposining manzilini login.github.io/sinov-repo/ ga almashtirdik. Portfolio — foydalanuvchi sayti, unda / yo'llar to'g'ri ishlaydi. landing — loyiha sayti: u yerda hamma yo'l nisbiy bo'lishi kerak. Yakuniy loyiha: landing da shunday qilgan edingiz.

5.3 SPA va 404 hiylasi (keyinroq kerak bo'ladi)

Keyingi qismlarda React kabi kutubxonalar bilan SPA (single-page application — bitta sahifali ilova) yozasiz. Kursda alohida o'rganamiz, hozir bilish shart emas. SPA'da /vazifalar/12 kabi manzillarni brauzerdagi JavaScript o'zi chizadi, serverda bunday fayl yo'q. Pages esa bunday manzilga 404 qaytaradi.

Keng tarqalgan hiyla — yig'ilgan index.html ning nusxasini 404.html deb ham joylash: Pages "topilmadi" sahifasi o'rniga ilovaning o'zini beradi. Ikkinchi sozlama — Vite (kursda keyin o'rganiladigan yig'ish vositasi) dagi base: '/landing/'. U loyiha saytida yo'llarni papkaga moslaydi. Ikkalasini vazifalar loyihasini Pages'ga chiqarganda ishlatasiz.

6. Yakuniy loyiha: portfolio va landing — avtomatik deploy

6.1 Vazifa

07-qism boshida portfolio'ingiz brauzer orqali yuklangan fayllar edi. Endi uni professional jamoadagidek yo'lga qo'yasiz:

login.github.io va landing repolari: har o'zgarish branch va PR'da, PR'da avtomatik tekshiruv, main himoyalangan, main ga merge bo'lganda tekshiruvdan o'tib, sayt o'zi yangilanadi.

6.2 Talablar

  1. Tarix: lokal repo GitHub bilan bog'langan, brauzer tarixi brauzer-tarixi tagida saqlangan (Remote), .gitattributes bor (.gitattributes).
  2. CI: .github/workflows/tekshiruv.yml — push va pull_request da npm run check (CI).
  3. Deploy: .github/workflows/pages.yml — check → deploy (needs), yozish huquqi faqat deploy da.
  4. Himoya: main himoyasi ruleset — PR majburiy, 0 tasdiq, chiziqli tarix, force-push va o'chirish taqiqi, check majburiy (loose) (Branch himoyasi).
  5. Ish oqimi: kamida bitta o'zgarish issue → branch → PR → yashil check → squash merge yo'lidan o'tgan (GitHub CLI).
  6. Sayt: https://login.github.io/ va https://login.github.io/landing/ ochiladi, CSS ishlaydi; package.json — 404.
  7. landing: xuddi shu ikki workflow va ruleset; Pages manbasi — GitHub Actions; hamma yo'llar nisbiy.

6.3 Ish tartibi

  1. Portfolio'da .gitattributes va tekshiruv.yml borligini tekshiring (oldingi darslarning portfolio qadamlari).
  2. feature/deploy-tekshiruv branchida pages.yml ni «Avval tekshir, keyin joyla» bo'limidagi ko'rinishga keltiring.
  3. Lokal tekshiruv: npx --yes @action-validator/cli .github/workflows/pages.yml va npm run check.
  4. Commit, push, gh pr create --fill, gh run watch, squash merge.
  5. main dagi Pages run'ini gh run watch bilan kuzating — check, keyin deploy.
  6. Saytni tekshiring (curl yoki brauzer, Ctrl + Shift + R).
  7. landing uchun 1–6 qadamlar.
  8. README'ga holat belgisi (badge) va sayt havolasi — ixtiyoriy, pastda.

6.4 Yechim bo'laklarda

Yechim: portfolio'dagi buyruqlar
bash
cd ~/kurs/portfolio
git switch main
git pull
git switch -c feature/deploy-tekshiruv
code .github/workflows/pages.yml
npx --yes @action-validator/cli .github/workflows/pages.yml
npm run check
git diff --stat

Sinov reposida git diff --stat:

text
 .github/workflows/pages.yml | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

16 qator qo'shildi (check ishi, needs, ish darajasidagi permissions), 2 qator o'chdi (yuqoridagi pages: write va id-token: write). Keyin:

bash
git add .github
git commit -m "Deploy: joylashdan oldin npm run check ni ishga tushir"
git push -u origin feature/deploy-tekshiruv
gh pr create --fill
gh pr checks --watch
gh pr merge --squash --delete-branch
gh run list --workflow pages.yml --limit 1
gh run watch <ID> --exit-status

gh pr checks --watch — tekshiruv tugaguncha kutadi. <ID> o'rniga gh run list ko'rsatgan raqam. Sinov reposida natija:

text
50ebc7b (HEAD -> main, origin/main, origin/HEAD) Deploy: joylashdan oldin npm run check ni ishga tushir (#10)
fe21169 Qator oxirlarini .gitattributes bilan tartibla (#9)
da02a02 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)

(git log --oneline -5.) Har qator — bitta PR: tarix chiziqli va o'qiladi. #9 — sinov reposiga keyinroq qo'shilgan .gitattributes, u yerda qisqaroq nom bilan. Sizning portfolio'ingizda u .gitattributes darsidan beri Git: qator oxirlarini .gitattributes bilan tartibla nomi bilan turibdi.

Yechim: landing

landing Yakuniy loyiha: landing da brauzer orqali yuklangan, Pages — "Deploy from a branch", fayllar ildizda. Lokal landing/ papkangizda esa fayllar sayt/ ichida. Portfolio bilan bir xil yo'l (Remote darsidagi "A yo'li"):

  1. kurs/landing — repo bo'lmasa git init, .gitignore (node_modules/), .gitattributes, birinchi commit.
  2. git remote add origin https://github.com/login/landing.git, git fetch, tarixni solishtirish, git tag brauzer-tarixi origin/main.
  3. Settings → Pages → Source → GitHub Actions — push'dan oldin.
  4. pages.yml va tekshiruv.yml — portfolio'dagi fayllarning aynan nusxasi (path: sayt ham bir xil).
  5. git push --force-with-lease -u origin main, keyin git push origin brauzer-tarixi.
  6. Birinchi Tekshiruv run'idan keyin — main himoyasi ruleset (GitHub CLI darsidagi gh api ... --input ruleset.json bilan bir buyruqda).

Sayt manzili: https://login.github.io/landing/. Yo'llar nisbiy bo'lgani uchun CSS va rasmlar joyida. Tekshirish: brauzer DevTools → Network — hamma fayl 200.

Yechim: README'ga holat belgisi (ixtiyoriy)

GitHub har workflow uchun holat rasmini (badge) beradi. Tayyor Markdown kodini olish (docs.github.com, "Adding a workflow status badge"):

  1. Repo → Actions → chap ro'yxatdan Pages workflow'i.
  2. "Filter workflow runs" maydoni yonidagi ... → Create status badge.
  3. Copy status badge Markdown — kod nusxalanadi.
  4. Uni README.md ning boshiga qo'ying (GitHub asoslari), ostiga — Sayt: https://login.github.io/.

Rasm manzili shu shaklda bo'ladi: github.com/login/login.github.io/actions/workflows/pages.yml/badge.svg.

Repo sahifasida yashil "Pages passing" belgisi chiqadi — ishga oluvchi bir qarashda loyiha ishlayotganini ko'radi.

6.5 Baholash

Majburiy shartlar: ikkala sayt ochiladi; main ga to'g'ridan-to'g'ri push GH013 bilan qaytadi; oxirgi Pages run'i yashil.

Ballar (jami 100, o'tish — 80):

Bo'lim Qanday tekshiriladi Ball
Tarix git log --oneline toza, brauzer-tarixi tagi GitHub'da, .gitattributes bor 10
CI gh pr checks — Tekshiruv/check yashil; ataylab xatoda qizil 15
Deploy pages.yml da needs: check; gh run view da check → deploy 20
Huquqlar Yozish huquqi faqat deploy ishida 10
Ruleset gh api .../rules/branches/main — 5 qoida, shu jumladan required_status_checks 15
Ish oqimi Kamida bitta issue → PR → merge, issue avtomatik yopilgan 10
Landing Ikkala workflow, ruleset, sayt /landing/ da CSS bilan 15
Sayt package.json — 404, 404 sahifa uslubli 5

Har bo'limda: hammasi bajarilgan — to'liq ball, bitta kamchilik — yarmi, ko'p — 0.

7. Portfolio'ga qo'shing

  1. Loyihalar sahifasi — «Bahor» landing kartasidagi "Kodni ko'rish" havolasi endi GitHub reposiga (https://github.com/login/landing) qaraydi.
  2. "Men haqimda" — ko'nikmalar ro'yxatiga: "Git, GitHub, Pull Request, GitHub Actions (CI va deploy)".
  3. Bu o'zgarishlarning o'zi ham issue → branch → PR → yashil check → merge yo'lidan o'tsin. Merge'dan bir-ikki daqiqa o'tib sayt yangilanganini tekshiring.

8. Ko'p uchraydigan xatolar

8.1 Pages manbasi hali "Deploy from a branch"

Workflow yashil, lekin sayt yangilanmaydi yoki deploy-pages qadami Pages topilmadi deb yiqiladi. Settings → Pages → Source → GitHub Actions ni tanlang.

8.2 Branch "..." is not allowed to deploy to github-pages

«Muhit himoyasi» bo'limidagi xabar. Branch'dan qo'lda deploy qilmoqchi bo'ldingiz. To'g'ri yo'l — PR va merge. Muhit qoidasini o'chirmang.

8.3 permissions ni ishga ko'chirib, contents: read ni unutish

Ish darajasidagi permissions yuqoridagini to'liq almashtiradi. deploy da faqat pages: write va id-token: write qolsa, contents huquqi bo'lmaydi va checkout private repoda kodni ololmaydi. Uchala qatorni yozing.

8.4 needs da xato nom

needs: tekshiruv, ish esa check deb nomlangan bo'lsa, GitHub workflow'ni umuman ishga tushirmaydi va Actions bo'limida xato ko'rsatadi. needs dagi nom — jobs: ostidagi aynan o'sha kalit.

8.5 / bilan boshlangan yo'llar loyiha saytida

«404 sahifa va loyiha saytidagi yo'l tuzog'i» bo'limi: landing da hamma yo'l nisbiy bo'lsin.

8.6 Domen DNS'i hali tarqalmagan

DNS yozuvini qo'shganingizdan keyin u butun internetga bir necha soatda tarqaladi. Windows'da tekshirish (GitHub hujjatidagi maslahat): PowerShell'da Resolve-DnsName www.example.com.

9. Mashqlar

Javoblarni mashqlar reposida 07/36-pages-deploy/javoblar.md ga yozib, 07/36: Pages deploy javoblarini qo'sh bilan commit qiling.

1-mashq (oson): Qaysi manba?

Har holat uchun Pages manbasini tanlang: "Deploy from a branch" yoki "GitHub Actions".

  1. Repo ildizida faqat index.html va style.css, tekshiruv kerak emas.
  2. Sayt sayt/ papkasida, ildizda package.json.
  3. Deploy'dan oldin npm run check majburiy.
Yechim

1 — branch (yoki Actions, ikkalasi ishlaydi; branch soddaroq). 2 — Actions: branch manbasi faqat / yoki /docs ni beradi. 3 — Actions: branch manbasida tekshiruv qadami yo'q.

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

yaml
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm run check
  deploy:
    [___:needs]: check
    permissions:
      contents: read
      pages: [___:write]
      id-token: write
    environment:
      name: [___:github-pages]

Ishora: «Avval tekshir, keyin joyla» bo'limidagi to'liq fayl. (Bu parchada setup-node ataylab tushirib qoldirilgan — 3-mashqqa qarang.)

Yechim

needs, write, github-pages. Muhit nomi aynan github-pages — uni GitHub Pages manbasi Actions'ga o'tganda o'zi yaratadi.

3-mashq (qiyin): Nega check yiqildi?

2-mashqdagi parcha bilan check ishi npm ci qadamida yiqilishi mumkin, yoki o'tib ketishi ham mumkin. Nega natija oldindan aniq emas? Qanday tuzatasiz?

Ishora: runner'da Node oldindan o'rnatilgan bo'lishi mumkin, lekin qaysi versiyasi? (CI darsidagi setup-node bo'limi.)

Yechim

setup-node qadami yo'q. Runner'da qandaydir Node versiyasi oldindan bor, lekin u GitHub tasvirining (image) yangilanishi bilan o'zgaradi — ubuntu-latest ning o'zi ham Ubuntu 24 dan 26 ga o'tmoqda. Bugun o'tgan workflow ertaga yiqilishi mumkin. Tuzatish — checkout dan keyin:

yaml
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm

Versiyani doim aniq yozing: CI takrorlanadigan bo'lishi kerak.

4-mashq: Portfolio qadami — 07-qism yakuni

Yakuniy loyiha («Yakuniy loyiha: portfolio va landing» bo'limi) — shu darsning portfolio qadami. Baholash jadvali bo'yicha o'zingizni tekshiring va natijani mashqlar/07/36-pages-deploy/javoblar.md ga yozing: har bo'lim balli va dalili (buyruq chiqishi yoki havola).

Yechim

Namuna — sinov reposidagi dalillar:

  • CI: ✓ Tekshiruv/check (pull_request) va ataylab xatoda X Tekshiruv/check (CI darsi).
  • Deploy: gh run view — ✓ check in 16s, ✓ deploy in 16s.
  • Ruleset: gh api "repos/{owner}/{repo}/rules/branches/main" --jq '.[].type' — deletion, non_fast_forward, required_linear_history, pull_request, required_status_checks.
  • Sayt: curl — bosh sahifa 200, package.json 404.

Sizning dalillaringiz shu ko'rinishda bo'ladi, faqat ID va SHA'lar boshqa.

10. 07-qism yakuni: endi nimalarni qila olasiz

Tabriklaymiz — Git va GitHub qismi tugadi! Endi bilasiz:

  • Git: uch hudud, commit, tarixni o'qish, xatoni qaytarish, branch, merge, rebase, stash, tag, reflog — va Git ichkaridan qanday ishlashi.
  • GitHub: remote, PR, code review, fork, issue, ruleset, gh.
  • Avtomatlashtirish: CI har PR'ni tekshiradi, deploy faqat tekshiruvdan keyin.

Eng muhimi — ish usuli: issue → branch → PR → yashil tekshiruv → merge → avtomatik deploy. Bu dunyodagi deyarli har dasturchilar jamoasining kundalik yo'li.

Oldinda: 08-qismda JavaScript boshlanadi. Har darsdagi mashqlar mashqlar reposiga commit qilinadi. Portfolio'ga birinchi JavaScript 09-qismda qo'shiladi va u ham shu yo'l bilan — PR, tekshiruv, deploy — saytga chiqadi.

11. Real ishda

  • "Main har doim deploy qilinadigan holatda" — ko'p jamoalarning asosiy qoidasi. Bugungi zanjir (ruleset + CI + needs) aynan shuni ta'minlaydi.
  • Muhitlar (environments) — real loyihada odatda bir nechta: staging (sinov serveri) va production. Production'ga joylash ko'pincha odam tasdig'ini talab qiladi.
  • Vercel, Netlify, Cloudflare Pages — Pages'ga o'xshash xizmatlar; ular har PR uchun alohida "preview" manzil ham beradi. Kursda Next.js bilan Vercel'ga chiqasiz.
  • CI/CD — bugun siz CD (continuous deployment — uzluksiz joylash) ning birinchi namunasini qurdingiz. To'liq pipeline — CI/CD tushunchasi darsida.
  • Intervyuda: "Deploy jarayoningiz qanday?" — endi aniq javob bera olasiz: PR, CI, himoyalangan main, avtomatik deploy.

Xulosa

  • Pages manbasi: branch (oddiy) yoki GitHub Actions (istalgan papka, tekshiruv, build).
  • pages.yml: upload-pages-artifact (path: sayt) → deploy-pages; concurrency — bir vaqtda bitta deploy.
  • needs: check — tekshiruvdan o'tmagan kod joylanmaydi; yozish huquqi faqat deploy ishida.
  • github-pages muhiti faqat main dan joylashga ruxsat beradi.
  • Custom domen — Settings → Pages + DNS (CNAME → login.github.io, A → 4 IP); Actions yo'lida CNAME fayl kerak emas; HTTPS bepul.
  • Loyiha saytida (/landing/) / bilan boshlanadigan yo'llar buziladi — nisbiy yo'l ishlating.

Keyingi dars: JavaScript nima va u qayerda ishlaydi — 08-qism boshlanadi: brauzer va Node.js'dagi birinchi dasturlaringiz.

Manbalar

  • GitHub Docs: "Configuring a publishing source for your GitHub Pages site", "Using custom workflows with GitHub Pages" — docs.github.com/pages
  • GitHub Docs: "Managing a custom domain for your GitHub Pages site", "Verifying your custom domain", "Securing your GitHub Pages site with HTTPS", "GitHub Pages limits" — docs.github.com
  • GitHub Docs: "Using jobs in a workflow" (needs), "Controlling permissions for GITHUB_TOKEN", "Managing environments for deployment" — docs.github.com/actions
  • actions/configure-pages, upload-pages-artifact, deploy-pages relizlari — github.com/actions
Ulashish:Telegram'da

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
GitHub Pages'ga avtomatik deploy: git push'dan saytgacha — 07-qism yakuniy loyihasi — IlmHamroh