Mundarija (43)
- Bu darsda
- 1. Nega bu kerak?
- 2. Pages manbasi: branch yoki Actions
- 2.1 Ikki yo'l
- 2.2 pages.yml qatorma-qator
- 3. Avval tekshir, keyin joyla
- 3.1 Ikki ish va needs
- 3.2 Haqiqiy run
- 3.3 Sayt tekshiruvi
- 3.4 Qizil holat: deploy o'tkazib yuboriladi
- 3.5 Muhit himoyasi: faqat main
- 4. Custom domen va HTTPS
- 4.1 Nega va qanday
- 4.2 CNAME fayli — Actions yo'lida kerak emas
- 4.3 HTTPS va domen tasdig'i
- 4.4 Pages qoidalari va chegaralari
- 5. 404 sahifa va loyiha saytidagi yo'l tuzog'i
- 5.1 404.html
- 5.2 Foydalanuvchi sayti va loyiha sayti
- 5.3 SPA va 404 hiylasi (keyinroq kerak bo'ladi)
- 6. Yakuniy loyiha: portfolio va landing — avtomatik deploy
- 6.1 Vazifa
- 6.2 Talablar
- 6.3 Ish tartibi
- 6.4 Yechim bo'laklarda
- 6.5 Baholash
- 7. Portfolio'ga qo'shing
- 8. Ko'p uchraydigan xatolar
- 8.1 Pages manbasi hali "Deploy from a branch"
- 8.2 Branch "..." is not allowed to deploy to github-pages
- 8.3 permissions ni ishga ko'chirib, contents: read ni unutish
- 8.4 needs da xato nom
- 8.5 / bilan boshlangan yo'llar loyiha saytida
- 8.6 Domen DNS'i hali tarqalmagan
- 9. Mashqlar
- 1-mashq (oson): Qaysi manba?
- 2-mashq (o'rta): Bo'sh joylarni to'ldiring
- 3-mashq (qiyin): Nega check yiqildi?
- 4-mashq: Portfolio qadami — 07-qism yakuni
- 10. 07-qism yakuni: endi nimalarni qila olasiz
- 11. Real ishda
- Xulosa
- Manbalar
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.ymlsaytniupload-pages-artifactbilan yuklaydi vadeploy-pagesbilan joylaydi. Workflow'gacheckishini qo'shib,deployganeeds: checkyozsangiz, tekshiruvdan o'tmagan kod saytga hech qachon chiqmaydi. Custom domen Settings → Pages'da ulanadi (Actions yo'lidaCNAMEfayl kerak emas), HTTPS bepul. Bu dars — 07-qism yakuniy loyihasi: portfolio va landinggit pushbilan o'zi yangilanadi.
Bu darsda
- Pages'ning ikki manbasini (branch va Actions) farqlay olasiz va
pages.ymlning har qatorini tushuntirasiz. - Deploy'dan oldin
npm run checkni qo'shasiz:needs, ish darajasidagipermissions. github-pagesmuhiti (environment) faqatmainga 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:
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@v5Yangi qatorlar:
permissions—pages: write(saytni joylash huquqi) vaid-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— "deploymentid'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):
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-artifactdapath: saytyozilgan, 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.
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@v5Uchta o'zgarish:
- Yangi
checkishi — CI darsidagi qadamlarning o'zi. Har ish o'z runner'ida ishlaydi, shuning uchuncheckoutikkala ishda ham bor. needs: check— "deployfaqatcheckmuvaffaqiyatli tugagandan keyin boshlansin".needsyo'q bo'lsa, ishlar parallel ketadi.permissionsishga ko'chdi. Yuqorida faqatcontents: readqoldi. Yozish huquqi faqatdeployda. Ish darajasidagipermissionsyuqoridagini to'liq almashtiradi, shuning uchuncontents: readu yerda qayta yozilgan. Natija:npm cio'rnatgan begona paketlar ishlaydigancheckishida 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:
gh run watch 36819531003 --exit-status✓ 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
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/200
404
404K 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:
curl -s https://login.github.io/assets/css/asosiy.css | tail -4
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:
gh workflow run pages.yml --ref feature/buzuq-sinov
gh run view 36819603186X 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?
gh workflow run pages.yml --ref feature/muhit-sinov
gh run view 36819631447X 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#1Tarjimasi: "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 —
maindan boshqa branch joylanmaydi. - Ruleset (Branch himoyasi, CI) —
mainga faqat yashil PR orqali.
Tekshirib ko'ring: Nega
checkishidapages: writehuquqi 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"):
- GitHub'da: Settings → Pages → "Custom domain" ga domenni yozasiz → Save.
- 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):
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153CNAME 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:
gh api "repos/{owner}/{repo}/pages" \
--jq '{html_url, build_type, https_enforced, cname}'{
"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.ioreposidan: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:
curl -s https://login.github.io/sinov-repo/yoq-sahifa \
| grep stylesheet <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:
404Ya'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.iovalandingrepolari: har o'zgarish branch va PR'da, PR'da avtomatik tekshiruv,mainhimoyalangan,mainga merge bo'lganda tekshiruvdan o'tib, sayt o'zi yangilanadi.
6.2 Talablar
- Tarix: lokal repo GitHub bilan bog'langan, brauzer tarixi
brauzer-tarixitagida saqlangan (Remote),.gitattributesbor (.gitattributes). - CI:
.github/workflows/tekshiruv.yml—pushvapull_requestdanpm run check(CI). - Deploy:
.github/workflows/pages.yml—check→deploy(needs), yozish huquqi faqatdeployda. - Himoya:
main himoyasiruleset — PR majburiy, 0 tasdiq, chiziqli tarix, force-push va o'chirish taqiqi,checkmajburiy (loose) (Branch himoyasi). - Ish oqimi: kamida bitta o'zgarish issue → branch → PR → yashil
check→ squash merge yo'lidan o'tgan (GitHub CLI). - Sayt:
https://login.github.io/vahttps://login.github.io/landing/ochiladi, CSS ishlaydi;package.json— 404. landing: xuddi shu ikki workflow va ruleset; Pages manbasi — GitHub Actions; hamma yo'llar nisbiy.
6.3 Ish tartibi
- Portfolio'da
.gitattributesvatekshiruv.ymlborligini tekshiring (oldingi darslarning portfolio qadamlari). feature/deploy-tekshiruvbranchidapages.ymlni «Avval tekshir, keyin joyla» bo'limidagi ko'rinishga keltiring.- Lokal tekshiruv:
npx --yes @action-validator/cli .github/workflows/pages.ymlvanpm run check. - Commit, push,
gh pr create --fill,gh run watch, squash merge. maindagiPagesrun'inigh run watchbilan kuzating —check, keyindeploy.- Saytni tekshiring (
curlyoki brauzer,Ctrl + Shift + R). landinguchun 1–6 qadamlar.- README'ga holat belgisi (badge) va sayt havolasi — ixtiyoriy, pastda.
6.4 Yechim bo'laklarda
Yechim: portfolio'dagi buyruqlar
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 --statSinov reposida git diff --stat:
.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:
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-statusgh pr checks --watch — tekshiruv tugaguncha kutadi. <ID> o'rniga gh run list ko'rsatgan raqam. Sinov reposida natija:
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"):
kurs/landing— repo bo'lmasagit init,.gitignore(node_modules/),.gitattributes, birinchi commit.git remote add origin https://github.com/login/landing.git,git fetch, tarixni solishtirish,git tag brauzer-tarixi origin/main.- Settings → Pages → Source → GitHub Actions — push'dan oldin.
pages.ymlvatekshiruv.yml— portfolio'dagi fayllarning aynan nusxasi (path: saytham bir xil).git push --force-with-lease -u origin main, keyingit push origin brauzer-tarixi.- Birinchi
Tekshiruvrun'idan keyin —main himoyasiruleset (GitHub CLI darsidagigh api ... --input ruleset.jsonbilan 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"):
- Repo → Actions → chap ro'yxatdan Pages workflow'i.
- "Filter workflow runs" maydoni yonidagi
...→ Create status badge. - Copy status badge Markdown — kod nusxalanadi.
- Uni
README.mdning 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
- Loyihalar sahifasi — «Bahor» landing kartasidagi "Kodni ko'rish" havolasi endi GitHub reposiga (
https://github.com/login/landing) qaraydi. - "Men haqimda" — ko'nikmalar ro'yxatiga: "Git, GitHub, Pull Request, GitHub Actions (CI va deploy)".
- 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".
- Repo ildizida faqat
index.htmlvastyle.css, tekshiruv kerak emas. - Sayt
sayt/papkasida, ildizdapackage.json. - Deploy'dan oldin
npm run checkmajburiy.
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
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:
- uses: actions/setup-node@v7
with:
node-version: 24
cache: npmVersiyani 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 xatodaX 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 sahifa200,package.json404.
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) vaproduction. 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 faqatdeployishida.github-pagesmuhiti faqatmaindan joylashga ruxsat beradi.- Custom domen — Settings → Pages + DNS (
CNAME→login.github.io,A→ 4 IP); Actions yo'lidaCNAMEfayl 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
Izohlar (0)
Izoh yozish uchun kiring.
- Hozircha izoh yo'q. Birinchi bo'ling!