Status checks — commit yoki pull request uchun avtomatik test, build, lint, security scan va boshqa tekshiruvlarning natijasini ko‘rsatuvchi holatlardir. Git hosting platformasi check run yoki commit statusni ma’lum commit SHA bilan bog‘laydi. Branch protection kerakli tekshiruvlar muvaffaqiyatli bo‘lmaguncha merge’ni bloklashi mumkin.
Commitga bog‘lanish
Status branch nomiga emas, aniq commitga tegishli. Pull requestga yangi commit push qilinsa oldingi yashil natija yangi kod uchun amal qilmaydi va checks qayta ishlaydi. Hosting platformasi base branch bilan vaqtinchalik merge commit yaratib, integratsiya holatini sinashi mumkin.
“Branch up to date” talabi main’dagi yangi commitlarni feature branchga integratsiya qilishni talab qiladi. Merge queue bir nechta pull requestni navbatda ehtimoliy yakuniy tartib bilan test qilib, main tez o‘zgarayotganida qayta test aylanasini boshqaradi.
Natija holatlari
Check queued, in progress, success, failure, cancelled, skipped yoki neutral kabi conclusionga ega bo‘lishi mumkin. Branch protection qaysi holatni qabul qilishini platforma belgilaydi. Workflow umuman ishga tushmagan yoki noto‘g‘ri path filter sabab skipped bo‘lganida required check abadiy pending qolishi mumkin.
Test command xatoni yutib exit code 0 qaytarsa check yashil ko‘rinadi. Pipeline faqat report yaratish emas, haqiqiy xato statusini runnerga uzatishi kerak.
Required checks
Repository admin aniq nomdagi checklarni required qiladi. Workflow job nomi o‘zgarsa protection eski nomni kutishi mumkin. Turli workflowlarda bir xil job nomi statusni noaniq qiladi. Barqaror, yagona nomlash va configuration review zarur.
Required checkni faqat ishonchli workflow yozishi kerak. Tashqi foydalanuvchi o‘z commit statusini kerakli context nomi bilan yubora olsa, himoyani chetlab o‘tishi mumkin. GitHub App yoki token permissionlari eng kam huquq bilan beriladi.
Test doirasi
Unit test tez, integration test xizmatlar orasidagi bog‘lanishni, end-to-end test asosiy foydalanuvchi oqimini tekshiradi. Barcha testni har kichik commitda bajarish qimmat bo‘lishi mumkin. Tez required qatlam va keyingi keng test bosqichlari ajratiladi.
Path filter faqat frontend o‘zgarsa backend testini o‘tkazib yuborishi mumkin, lekin umumiy schema yoki build config ikki tomonga ta’sir qiladi. Dependency graphga asoslangan selective test noto‘g‘ri salbiy natija bermasligi uchun konservativ ishlaydi.
Flaky test
Bir xil kodda ba’zan o‘tib, ba’zan yiqiladigan test flaky hisoblanadi. Ko‘r-ko‘rona retry yashil check bera oladi, ammo ishonchni pasaytiradi. Timing, umumiy state, network va noto‘g‘ri isolation sababi topiladi. Retry soni va flaky rate alohida metrika sifatida kuzatiladi.
Security
Fork pull request checklari ishonchsiz kodni bajaradi. Secretlar berilmaydi, runner izolyatsiya qilinadi. Check log va artifact’da token, shaxsiy ma’lumot yoki production dump qolmasligi kerak. Deployment status checkdan alohida environment approval talab qilishi mumkin.
Check identifikatsiyasi
Branch qoidasi odatda status checkni ko‘rinadigan nomi yoki integratsiya identifikatori bilan talab qiladi. Turli workflowlar bir xil nom yuborsa, kutilmagan check talabni qondirib qo‘yishi mumkin. Shu bois job nomlari barqaror va maqsadga xos tanlanadi. Matrix joblarda platforma parametrlarni nomga qo‘shishi mumkin; required check sozlamasi aynan hosil bo‘ladigan nomlarga mos bo‘lishi zarur. Workflow fayli o‘zgarganda yangi check nomi paydo bo‘lib, eskisi endi yaratilmasa, pull request doim kutish holatida qoladi. Qoidani yangilashdan oldin eski va yangi workflow bir necha commitda parallel ishlatilishi migratsiyani uzluksiz qiladi.
Bog‘liq tushunchalar
CI/CD, branch protection, pull request, test automation, check run, merge queue, GitHub Actions