Linter va kod sifati - CI/CD va GitHub Actions

Testlar kod nima qilishini tekshiradi. Linter esa kod qanday yozilganini tekshiradi: ishlatilmagan o'zgaruvchi, xavfli solishtirish, eskirgan konstruksiya. Ikkalasi bir-birini almashtirmaydi.

Linter nimani topadi #

Quyidagi fayl ishlaydi - lekin unda uchta muammo bor:

JavaScript

var soni = 10;
const ism = "Husanboy";

export function tekshir(qiymat) {
    if (qiymat == "5") {
        return true;
    }
    return false;
}

ESLint ni ishga tushiramiz:

Terminal

npx eslint yomon.js

Natija

  1:1   error  Unexpected var, use let or const instead   no-var
  1:5   error  'soni' is assigned a value but never used  no-unused-vars
  2:7   error  'ism' is assigned a value but never used   no-unused-vars
  5:16  error  Expected '===' and instead saw '=='        eqeqeq

✖ 4 problems (4 errors, 0 warnings)
  1 error and 0 warnings potentially fixable with the `--fix` option.

Terminal

echo $?

Natija

Chiqish kodi 1 - demak CI buni qizil deb biladi va job to'xtaydi.

== nega xato

qiymat == "5" yozuvi JavaScript da turlarni avtomatik almashtiradi: 5 == "5" rost bo'ladi, 0 == "" ham rost bo'ladi. Bu kutilmagan xatolar manbai.

=== esa turni ham solishtiradi. Linter shuni talab qiladi - va bu xatolarning butun bir sinfini yo'q qiladi.

Linter va formatlovchi - ikki xil vosita #

	Linter (ESLint, Pylint, PHPStan)	Formatlovchi (Prettier, Black, gofmt)
Nimani tekshiradi	Mantiq va xavfli naqshlar	Faqat ko'rinish: bo'shliq, qator uzunligi
Misol	«Bu o'zgaruvchi ishlatilmayapti»	«Bu yerda 4 emas, 2 probel bo'lsin»
Bahsli joyi	Qoidalarni tanlash kerak	Deyarli yo'q - vosita o'zi hal qiladi
CI dagi roli	Xatoni topadi	Munozarani yo'q qiladi

Ikkalasini birga ishlatish odatiy amaliyot: formatlovchi uslub haqidagi bahsni tugatadi, linter esa haqiqiy muammolarni ko'rsatadi.

Quvurga ulash #

YAML

name: Kod sifati

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

jobs:
  linter:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - run: npm ci

      - name: Linter
        run: npx eslint .

      - name: Format tekshiruvi
        run: npx prettier --check .

Linterni testlardan alohida jobda ishlating

Linter bir necha soniyada tugaydi, testlar esa daqiqalar oladi. Ularni ajratsangiz:

ikkalasi parallel ishlaydi - umumiy vaqt oshmaydi;
PR sahifasida qaysi biri yiqilgani darhol ko'rinadi;
linter xatosi uchun testlarni kutish shart bo'lmaydi.

Bitta jobda ketma-ket yozsangiz, linter yiqilganda testlar umuman ishlamaydi - va siz ikkinchi muammoni faqat birinchisini tuzatgandan keyin ko'rasiz.

Formatni tekshirish, o'zgartirmaslik #

CI da formatlovchi tekshirish rejimida ishlaydi:

Buyruq	Nima qiladi	Qayerda
`prettier --write .`	Fayllarni o'zgartiradi	Mahalliy kompyuterda
`prettier --check .`	Faqat xabar beradi, tegmaydi	CI da

Natija

Checking formatting...
[warn] src/hisob.js
[warn] Code style issues found in the above file. Run Prettier with --write to fix.

CI kodni o'zi tuzatib, kommit qilmasin

Ba'zi jamoalar quvurga «formatla va kommit qil» qadamini qo'shadi. Bu chiroyli ko'rinadi, lekin muammolar keltiradi:

Muammo	Nima bo'ladi
Cheksiz sikl	Bot kommiti yangi ishga tushirishni boshlaydi
Tarix ifloslanadi	Har PR da «format» kommitlari
Mualliflik chalkashadi	O'zgarishni kim kiritgani noaniq
PR tasdiqlangandan keyin o'zgaradi	Ko'rib chiqilgan kod boshqasiga aylanadi

To'g'ri yo'l: mahalliy kompyuterda --write, CI da esa faqat --check. Kodni tuzatish - muallifning ishi.

Xato qanchalik erta ushlansa, shunchalik arzon tuzatiladi

Faqat o'zgargan fayllarni tekshirish #

Katta loyihada butun kod bazasini tekshirish sekin. PR da faqat tegilgan fayllarni tekshirish mumkin:

YAML

      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: O'zgargan fayllarni tekshirish
        run: |
          fayllar=$(git diff --name-only --diff-filter=ACM origin/main...HEAD -- '*.js')
          if [ -z "$fayllar" ]; then
            echo "JS fayllar o'zgarmagan"
            exit 0
          fi
          echo "$fayllar"
          npx eslint $fayllar

fetch-depth: 0 bu yerda majburiy: solishtirish uchun main tarmog'ining tarixi kerak, sukutdagi bitta kommit yetmaydi.

Eski kodga qoidalarni birdan joriy qilmang

Mavjud loyihaga linter qo'shsangiz, birinchi ishga tushirish minglab xato beradi. Bu jamoani qo'rqitadi va odatda hammasi o'chiriladi.

Bosqichma-bosqich yo'l ishonchliroq:

Avval faqat yangi va o'zgargan fayllarni tekshiring.
Eng xavfli qoidalarni (eqeqeq, no-unused-vars) yoqing, qolganini keyinroq.
Eski fayllarni modul-modul tozalab boring.
Hammasi tozalangach, butun loyihaga o'ting.

Xatolarni PR ichida ko'rsatish #

Jurnalga qaramasdan, xatoni to'g'ridan-to'g'ri kod yonida ko'rsatish mumkin. Buning uchun linter natijasi GitHub tushunadigan formatga o'tkaziladi:

YAML

      - name: Linter (izohlar bilan)
        run: npx eslint . --format=@microsoft/eslint-formatter-sarif --output-file=natija.sarif
        continue-on-error: true

      - name: Natijani yuklash
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: natija.sarif

Endi xatolar PR ning Files changed bo'limida, aynan o'sha qatorda ko'rinadi.

continue-on-error: true bu yerda kerak: linter yiqilsa ham, natija yuklanishi kerak. Aks holda eng kerakli paytda izohlar bo'lmaydi.

Boshqa tillar uchun #

Til	Linter	Formatlovchi
JavaScript, TypeScript	ESLint	Prettier
Python	Ruff, Pylint	Black, Ruff
PHP	PHPStan, Psalm	PHP-CS-Fixer
Go	`go vet`, staticcheck	`gofmt` (tilning o'zida)
Java	Checkstyle, SpotBugs	Spotless
Shell skriptlar	ShellCheck	shfmt
YAML fayllari	yamllint	-
Workflow fayllari	actionlint	-

O'z workflow fayllaringizni ham tekshiring

actionlint workflow fayllaridagi xatolarni topadi: noto'g'ri kalit, mavjud bo'lmagan konteks, shell skriptidagi muammo.

YAML

      - name: Workflow fayllarini tekshirish
        run: |
          curl -sSfL https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash | bash
          ./actionlint

Bu quvurning o'zini tekshiradigan quvur - va u haqiqatan xato topadi.

Amaliy topshiriq

Loyihangizga ESLint (yoki tilingizga mos linter) o'rnating.
Uchta qoida yoqing: ishlatilmagan o'zgaruvchi, qat'iy solishtirish, eskirgan konstruksiya.
Ataylab xato kod yozib, linterni mahalliy ishga tushiring va chiqish kodini tekshiring.
Linterni alohida jobda quvurga ulang.
Testlar jobi bilan parallel ishlayotganiga ishonch hosil qiling.
Prettier (yoki mos formatlovchi) ni --check rejimida qo'shing.
Formatni ataylab buzib, quvur qizil bo'lishini ko'ring va mahalliy --write bilan tuzating.
Faqat o'zgargan fayllarni tekshiradigan qadam yozing.
fetch-depth: 0 ni olib tashlab, nima uchun xato chiqishini tushuntiring.
actionlint ni qo'shib, o'z workflow fayllaringizni tekshiring.

Xulosa #

Linter kod qanday yozilganini, test esa nima qilishini tekshiradi - ikkalasi kerak.
Linter xato topsa 0 dan boshqa chiqish kodi qaytaradi va job qizil bo'ladi.
Formatlovchi uslub haqidagi bahsni tugatadi, linter esa haqiqiy muammolarni ko'rsatadi.
Linterni testlardan alohida jobda ishlating - ular parallel bo'ladi va xato aniq ko'rinadi.
CI da formatlovchi --check rejimida ishlaydi, --write emas.
CI kodni o'zi tuzatib kommit qilmasin - bu cheksiz sikl va iflos tarix keltiradi.
Katta loyihada faqat o'zgargan fayllarni tekshirish mumkin; bunda fetch-depth: 0 kerak.
Eski loyihaga qoidalarni bosqichma-bosqich joriy qiling, birdan emas.
SARIF formati xatolarni PR ning Files changed bo'limida ko'rsatadi.
actionlint workflow fayllarining o'zini tekshiradi.

Keyingi bo'limda qurish natijalarini - artefaktlarni saqlash va ular bilan ishlashni ko'ramiz.

Linter nimani topadi #

Linter va formatlovchi - ikki xil vosita #

Quvurga ulash #

Formatni tekshirish, o'zgartirmaslik #

Faqat o'zgargan fayllarni tekshirish #

Xatolarni PR ichida ko'rsatish #

Boshqa tillar uchun #

Xulosa #

Xatolik topdingizmi?