Nette Documentation Preview

syntax 
Průběžná integrace
******************

.[perex]
DressCode v GitHub Actions, GitLabu a dalších CI: formát výstupu, který si pipeline vybere sama, anotace v pull requestu, cache mezi běhy a exit kódy jako smlouva.


Co v CI spouštět
================

`check`, ne `fix`. CI má říct, jestli je kód v pořádku, a exit kód `1` u porušení job shodí; opravu dělá vývojář lokálně, kde ji vidí. Kdo chce, aby CI opravy i nabídlo, pustí `fix` a pak `git diff --exit-code`; diff ve výpisu jobu je pak přesně to, co má vývojář commitnout.

Exit kódy jsou smlouva: `0` čisto, `1` porušení nebo soubor, který nejde parsovat, `2` selhání nástroje (špatná konfigurace, výjimka v pravidle). Na `2` má job selhat hlasitěji než na `1`, protože znamená, že se nic nezkontrolovalo.


GitHub Actions
==============

```yaml
name: Code style

on: [push, pull_request]

jobs:
  dresscode:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-progress --prefer-dist
      - run: vendor/bin/dresscode check
```

Nic víc není potřeba: DressCode pozná, že běží jako krok GitHub Actions, a přepne výstup na formát `github`, ve kterém je každé porušení anotace. V pull requestu se pak ukáže přímo u řádku, kterého se týká, se zprávou a jménem pravidla. Ve výpisu jobu zůstane shrnutí.

Barvy se vypnou samy, protože výstup není terminál; `--no-color` psát nemusíte.


GitLab, Jenkins a ostatní
=========================

Kde není nativní formát, je `checkstyle`, kterému rozumí Jenkins, `cs2pr` i většina převodníků na formát Code Quality GitLabu, a `json` pro vlastní zpracování:

```yaml
dresscode:
  script:
    - composer install --no-progress
    - vendor/bin/dresscode check -f checkstyle > dresscode.xml
  artifacts:
    when: always
    paths: [dresscode.xml]
```

Oba formáty jsou stabilní napříč minoritními verzemi; `console` a `github` ne, ty jsou pro lidi.


Cache mezi běhy
===============

DressCode si pamatuje otisky souborů, které byly čisté, v systémovém dočasném adresáři; v CI, kde každý běh začíná načisto, z toho nic nemá. Když cache nasměrujete do projektu a ten adresář necháte CI uchovat, druhý běh zkontroluje jen změněné soubory:

```neon
cacheDir: temp/dresscode
```

```yaml
      - uses: actions/cache@v4
        with:
          path: temp/dresscode
          key: dresscode-${{ hashFiles('composer.lock', 'dresscode.neon') }}
```

Klíč cache obsahuje i otisk konfigurace a verzí nainstalovaných balíčků, takže po změně konfigurace nebo aktualizaci DressCode se soubory zkontrolují znovu samy; hash v klíči jobu je jen proto, aby se stará cache neuchovávala navěky.


Paralelní běh a verze
=====================

Počet pracovních procesů se řídí počtem procesorů běžce, takže na dvoujádrovém běžci není co ladit; na velkém stroji s mnoha jádry pomůže `--jobs 8`. Verzi DressCode pinujte v `composer.lock` jako každou jinou závislost: nové pravidlo v minoritní verzi může začít hlásit něco, co dosud procházelo, a to se má stát při vědomé aktualizaci, ne v cizím pull requestu.

Průběžná integrace

DressCode v GitHub Actions, GitLabu a dalších CI: formát výstupu, který si pipeline vybere sama, anotace v pull requestu, cache mezi běhy a exit kódy jako smlouva.

Co v CI spouštět

check, ne fix. CI má říct, jestli je kód v pořádku, a exit kód 1 u porušení job shodí; opravu dělá vývojář lokálně, kde ji vidí. Kdo chce, aby CI opravy i nabídlo, pustí fix a pak git diff --exit-code; diff ve výpisu jobu je pak přesně to, co má vývojář commitnout.

Exit kódy jsou smlouva: 0 čisto, 1 porušení nebo soubor, který nejde parsovat, 2 selhání nástroje (špatná konfigurace, výjimka v pravidle). Na 2 má job selhat hlasitěji než na 1, protože znamená, že se nic nezkontrolovalo.

GitHub Actions

name: Code style

on: [push, pull_request]

jobs:
  dresscode:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-progress --prefer-dist
      - run: vendor/bin/dresscode check

Nic víc není potřeba: DressCode pozná, že běží jako krok GitHub Actions, a přepne výstup na formát github, ve kterém je každé porušení anotace. V pull requestu se pak ukáže přímo u řádku, kterého se týká, se zprávou a jménem pravidla. Ve výpisu jobu zůstane shrnutí.

Barvy se vypnou samy, protože výstup není terminál; --no-color psát nemusíte.

GitLab, Jenkins a ostatní

Kde není nativní formát, je checkstyle, kterému rozumí Jenkins, cs2pr i většina převodníků na formát Code Quality GitLabu, a json pro vlastní zpracování:

dresscode:
  script:
    - composer install --no-progress
    - vendor/bin/dresscode check -f checkstyle > dresscode.xml
  artifacts:
    when: always
    paths: [dresscode.xml]

Oba formáty jsou stabilní napříč minoritními verzemi; console a github ne, ty jsou pro lidi.

Cache mezi běhy

DressCode si pamatuje otisky souborů, které byly čisté, v systémovém dočasném adresáři; v CI, kde každý běh začíná načisto, z toho nic nemá. Když cache nasměrujete do projektu a ten adresář necháte CI uchovat, druhý běh zkontroluje jen změněné soubory:

cacheDir: temp/dresscode

      - uses: actions/cache@v4
        with:
          path: temp/dresscode
          key: dresscode-${{ hashFiles('composer.lock', 'dresscode.neon') }}

Klíč cache obsahuje i otisk konfigurace a verzí nainstalovaných balíčků, takže po změně konfigurace nebo aktualizaci DressCode se soubory zkontrolují znovu samy; hash v klíči jobu je jen proto, aby se stará cache neuchovávala navěky.

Paralelní běh a verze

Počet pracovních procesů se řídí počtem procesorů běžce, takže na dvoujádrovém běžci není co ladit; na velkém stroji s mnoha jádry pomůže --jobs 8. Verzi DressCode pinujte v composer.lock jako každou jinou závislost: nové pravidlo v minoritní verzi může začít hlásit něco, co dosud procházelo, a to se má stát při vědomé aktualizaci, ne v cizím pull requestu.