CI i SDLC

Rozwój to pętla

Mała zmiana. Szybka odpowiedź.

Błąd wykryty po kilku minutach łatwiej połączyć z konkretną zmianą niż problem odkryty po tygodniu.

Zielony build nie jest wdrożeniem

Jedna platforma może realizować wszystkie trzy procesy. O tym, co się stało, decydują wykonane kroki, nie nazwa narzędzia.

Testy mają różny zakres

Lint i analiza statyczna uzupełniają testy. Zielony wynik dowodzi przejścia skonfigurowanych sprawdzeń, nie braku wszystkich błędów.

Automat sprawdza. Człowiek ocenia.

GitHub Flow: main + feature

• Zmianę zaczynamy z aktualnego main; PR można otworzyć jeszcze jako draft.
• Kolejne commity aktualizują ten sam PR i jego sprawdzenia.
• Po akceptacji integrujemy zmianę, usuwamy feature i utrzymujemy main gotowy do wydania.

GitHub Flow

Merge zachowuje gałąź. Squash scala zmianę.

Fast-forward przesuwa wskaźnik

git switch main
git pull --ff-only

To kontrola historii commitów, nie sposób zapisywania niezacommitowanych plików. GitHub „Rebase and merge” jest inną operacją niż lokalny fast-forward.

Release oddziela stabilizację od rozwoju

Feature: develop → feature → develop. Release: develop → release → main i develop, żeby poprawki nie zginęły.

Hotfix wraca do obu linii

Nie trzeba wydawać całego niestabilnego develop, aby poprawić błąd produkcyjny.

Przy aktywnej gałęzi release hotfix przenosimy także do niej; późniejsze scalenie release zasili develop.

Więcej gałęzi ≠ lepsza integracja

Autor Git Flow sam zaleca prostszy model dla oprogramowania dostarczanego ciągle.

Vincent Driessen — Git Flow i refleksja autora z 2020 r.

Nie tylko GitHub Actions

GitHub · GitLab · Jenkins · Azure · CircleCI · TeamCity

Kto planuje? Kto wykonuje?

Porównujemy zgodność środowiska, cache, sieć, koszt i granice zaufania — nie tylko czas jednego builda.

Standardowe runnery GitHub-hosted są bezpłatne dla publicznych repozytoriów. Limity prywatnych zależą od planu; większe runnery są płatne także publicznie.

Blacksmith — dokumentacja · Depot — dokumentacja · Rozliczanie GitHub Actions

Mapa ma klucze. Lista ma elementy.

jobs:
  hello:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Cześć"
      - run: pwd

Workflow zapisujemy w repozytorium jako plik .github/workflows/hello.yml lub .yaml.

Pierwszy workflow: Hello CI

name: Hello CI
on: push
permissions: {}
jobs:
  hello:
    name: Powitanie
    runs-on: ubuntu-24.04
    steps:
      - name: Wiadomość
        shell: bash
        run: echo "CI działa!"
      - name: System
        shell: bash
        run: uname -s

Powiąż wynik z commitem

1. Na liście Actions znajdź Hello CI.
2. W run sprawdź zdarzenie push, gałąź i SHA.
3. Graf zawiera job Powitanie.
4. W logu kroku Wiadomość odczytaj CI działa!.

Nie każdy krok logu pochodzi z YAML

Po pracy mogą pojawić się także kroki sprzątania. Nazwa kroku ułatwia połączenie logu z definicją.

Lista nie zawsze wymaga dodatkowego wcięcia

steps:
  - name: Wiadomość
    run: echo "Cześć"
  - name: Katalog
    run: pwd

steps:
- name: Wiadomość
  run: echo "Cześć"
- name: Katalog
  run: pwd

• YAML dopuszcza niewciętą sekwencję blokową jako wartość klucza mapy.
• name i run nadal muszą należeć do tego samego elementu.
• Wybierz jedną konwencję. Nie zastępuj spacji tabulatorami.

on: push to skalar zaakceptowany przez Actions

on: push

on:
  - push
  - pull_request

on:
  push:
    branches: [main]

YAML pozwala przypisać kluczowi tekst, listę lub mapę. Schemat GitHub Actions dopuszcza te postacie właśnie dla on.

To nie znaczy, że dowolny klucz workflow przyjmuje dowolny typ wartości.

Workflow syntax — on

Cudzysłów chroni znaczenie tekstu

name: "Build: API #1"
env:
  FLAG: "false"
  NOTICE: "! to jest tekst"
  LABEL: 'Raport #1'

# Komentarz, nie wartość
permissions: {contents: read}

| zachowuje linie. >- je składa.

- shell: bash
  run: |
    echo "Początek"
    pwd
    uname -s

- run: >-
    printf '%s\n'
    'Jeden argument tekstowy'

> zwykle składa kolejne linie w spacje; znak - usuwa końcowy znak nowej linii. Puste i dodatkowo wcięte linie mają osobne reguły.

Wewnątrz run: | znajduje się tekst skryptu. Jego komentarze i cudzysłowy interpretuje już powłoka.

JSON mieści się w YAML

on: [push, workflow_dispatch]
permissions:
  contents: read

{
  "on": ["push", "workflow_dispatch"],
  "permissions": {"contents": "read"}
}

YAML 1.2 jest nadzbiorem JSON. Wartość można zapisać w stylu JSON; da się tak zapisać również cały workflow.

Plik nadal umieszczamy w .github/workflows/ z rozszerzeniem .yml lub .yaml, nie .json.

Specyfikacja YAML 1.2.2

W run i script jest kolejny język

- shell: bash
  run: echo "$GITHUB_SHA"
- uses: actions/github-script@v9
  with: {script: "core.notice('CI');"}
- if: ${{ github.ref == 'refs/heads/main' }}
  shell: bash
  run: echo main

- shell: bash
  run: echo "$GITHUB_SHA"
- uses: actions/github-script@v9
  with: {script: "core.notice('CI');"}
- if: ${{ github.ref == 'refs/heads/main' }}
  shell: bash
  run: echo main

Tekst jest identyczny. Po prawej mechanizm strony koloruje jawny Bash, github-script i expressions podczas budowania HTML. To nie jest symulacja interfejsu IDE.

Podpowiedź, walidacja, inspekcja

# language=githubexpressionlanguage
if: >-
  ${{ github.ref == 'refs/heads/main' }}

actionlint
yq '.jobs.hello.steps' \
  .github/workflows/hello.yml

actionlint · yq

Workflow opisuje. Run jest zdarzeniem w historii.

• Runner to środowisko wykonujące job.
• Step uruchamia polecenie run albo komponent uses.
• Action to komponent wywołany w kroku, nie dodatkowy poziom między jobem a runnerem.

name to etykieta. id to identyfikator.

name: Kontrola projektu
run-name: Sprawdzenie zmiany
jobs:
  verify:
    name: Build i testy
    runs-on: ubuntu-24.04
    steps:
      - name: Wersja systemu
        id: system
        run: uname -s

Kroki kolejno. Jobs mogą równolegle.

jobs:
  lint:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Krok 1"
      - run: echo "Krok 2"
  docs:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Osobny job"

needs mówi: najpierw to zadanie

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Budowanie"
  verify:
    needs: build
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Weryfikacja"

Polecenie albo gotowy komponent

- name: Pokaż narzędzie
  shell: bash
  run: dotnet --info

- name: Przygotuj .NET
  uses: actions/setup-dotnet@v6
  with:
    dotnet-version: '10.x'

Nie łączymy run i uses w jednym kroku. Komenda node skrypt.js nadal jest krokiem run, a nie automatycznie JavaScript action.

System wybiera runs-on

Actions nie działa zawsze na Linuksie ani na Twoim laptopie. W tych przykładach wybieramy Ubuntu, żeby pokazywać jedną spójną składnię Bash.

Lista etykiet wymaga ich jednoczesnego dopasowania; nie oznacza kilku systemów do uruchomienia.

Kod i narzędzia przygotowujemy osobno

steps:
  - uses: actions/checkout@v7
  - uses: actions/setup-node@v7
    with:
      node-version: '24'
      package-manager-cache: false
  - run: node --version

Numer przy nazwie action określa jej wersję. Wersja instalowanego Node jest osobnym inputem.

Typ action zapisuje jej autor

runs:
  using: node24
  main: dist/index.js

runs:
  using: docker
  image: Dockerfile

runs:
  using: composite
  steps:
    - shell: bash
      run: echo "CI"

Wszystkie wywołujemy przez step z uses. Action nie wybiera własnego runs-on. Runtime JS action jest niezależny od Node instalowanego dla aplikacji.

Metadata syntax — runs

Gdzie działa skrypt? Gdzie działa baza?

runs-on: ubuntu-24.04
container: node:24-bookworm
steps:
  - run: node --version

runs-on: ubuntu-24.04
services:
  postgres:
    image: postgres:17
    env:
      POSTGRES_PASSWORD: ci-only
    ports: ['5432:5432']

Gdy sam job działa w kontenerze, usługę osiąga po nazwie postgres:5432. Przed testami trzeba zaczekać na gotowość bazy, np. przez healthcheck.

Docker action nie zamienia całego joba w kontener

# Fragment steps w jobie na runnerze Linux
- run: uname -s
- uses: docker://alpine:3.22
  with:
    entrypoint: /bin/sh
    args: -c "uname -s"
- run: echo "Znowu krok na runnerze"

• Kontener dostarcza implementację tego jednego kroku.
• To nie jobs.<id>.container ani długotrwała usługa z services.
• GameCI unity-builder@v4 uruchamia kontenery, ale ma runs.using: node20. To JavaScript action, nie Docker action.

Actions z obrazów Docker · GameCI v4 — metadata · Metadata prawdziwej Docker action

PR przed integracją. Push po integracji.

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

W Git Flow trzeba uwzględnić również PR-y do develop lub release. Push na każdą gałąź obok triggera PR może tworzyć dwa runs dla jednej zmiany.

Uwaga: pull_request_target

Nie pobieraj i nie wykonuj niezaufanego kodu PR-a z uprawnieniami bazowego repozytorium.

Zmiana triggera nie jest bezpieczną „naprawą” braku sekretów w zwykłym PR.

pull_request_target — kontekst i ostrzeżenia

Harmonogram korzysta z gałęzi domyślnej

on:
  schedule:
    - cron: '15 5 * * 1-5'
      timezone: Europe/Warsaw

• Cron: minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia. Najkrótszy obsługiwany interwał to 5 minut.
• Plik workflow i wykonywany commit pochodzą z gałęzi domyślnej.
• Obciążenie usługi może opóźnić lub spowodować pominięcie run. To nie zegar czasu rzeczywistego.
• W publicznym repozytorium 60 dni bez aktywności wyłącza zaplanowane uruchomienia.

Schedule — cron, timezone i opóźnienia

Ręczny start przez Run workflow

on:
  workflow_dispatch:

• Najpierw umieść workflow na gałęzi domyślnej, aby korzystać z przycisku Run workflow.
• W UI wybieramy gałąź uruchomienia; API i CLI również potrafią wywołać dispatch.
• Można zdefiniować formularz inputów — zrobimy to w następnej sekcji.
• Checks z workflow_dispatch nie spełniają wymaganych checks w rulesecie gałęzi, nawet dla tego samego SHA. Do sprawdzeń PR używamy pull_request.

Required status checks — ręczne uruchomienia

Skip jest częścią komunikatu commita

docs: popraw opis [skip ci]

docs: popraw opis

Uzupełnij przykład w dokumentacji.


skip-checks: true

Dotyczy push i pull_request; dla PR liczy się komunikat HEAD commita. Nie wyłącza pull_request_target, schedule ani dispatch.

Wymagany check pominiętego workflow może pozostać Pending / Expected i blokować merge.

Skipping workflow runs

Którą rewizję sprawdza PR?

Domyślny checkout dla zwykłego PR sprawdza przygotowane połączenie zmian z bazą, a nie tylko HEAD autora.

pull_request — SHA i ref

Main może pójść naprzód po teście

• Merge ref pozwala testować połączenie nawet wtedy, gdy feature powstał ze starszego main.
• Konflikt scalenia może uniemożliwić start zwykłego workflow PR.
• Nie zakładaj, że każdy późniejszy push do main ponownie sprawdzi wszystkie otwarte PR-y.

Wymaganie aktualnej bazy albo merge queue pomaga kontrolować stan tuż przed scaleniem.

@v7 nie jest wersją aplikacji

- uses: actions/checkout@v7
  with:
    ref: ${{ github.sha }}

Zwykle pomijamy with.ref, pozostawiając domyślną rewizję zdarzenia. W samym uses ref musi być statyczny — nie tworzymy go wyrażeniem.

Zadeklaruj formularz uruchomienia

on:
  workflow_dispatch:
    inputs:
      configuration:
        description: Konfiguracja builda
        type: choice
        options: [Debug, Release]
        default: Release
        required: true
      verbose:
        description: Pokaż szczegóły
        type: boolean
        default: false

Wartość formularza trafia do inputs

run-name: "CI · ${{ inputs.configuration }}"

Odczyt tego samego inputu w liście steps:

- name: Pokaż wybrany tryb
  env:
    CONFIGURATION: ${{ inputs.configuration }}
  run: |
    printf 'Tryb: %s\n' "$CONFIGURATION"
- name: Dodatkowe informacje
  if: ${{ inputs.verbose }}
  run: echo "Włączono szczegółowe informacje"

• ${{ ... }} odczytuje wartość w silniku Actions.
• env przekazuje ją jako tekst do procesu Bash.
• if może bezpośrednio użyć boolean z typowanego inputu.

Typy deklarujemy na wejściu workflow

W dispatch używaj kontekstu inputs, który zachowuje typy. Wariant github.event.inputs przekazuje wartości tekstowe.

Konsument nadal powinien sprawdzić dozwolone wartości i zakres, np. czy liczba jest dodatnia.

Kontekst ma konkretne źródło

Nie każdy kontekst jest dostępny w każdym polu. Na przykład runner nie istnieje jeszcze podczas oceny warunku joba.

Tabela dostępności kontekstów

Jawna konfiguracja i chronione wartości

env:
  CONFIGURATION: ${{ vars.BUILD_MODE }}
  DOCS_TOKEN: ${{ secrets.DOCS_TOKEN }}

Token dostaje tylko potrzebne prawa

# Domyślnie w workflow
permissions:
  contents: read

# Osobno w jobie komentującym PR
# permissions:
#   pull-requests: write

Permissions joba określa jego zestaw praw — nie dopisuje automatycznie pozostałych praw z workflow. Fork i polityki organizacji mogą dodatkowo ograniczyć dostęp.

Workflow syntax — permissions

if decyduje przed uruchomieniem kroku

- name: Informacja po zmianie main
  if: ${{ github.ref == 'refs/heads/main' }}
  run: echo "To uruchomienie dotyczy main"

• == porównuje wartości. Tekst wewnątrz expression zapisujemy w pojedynczych apostrofach.
• W polu if zwykle wolno pominąć ${{ }}.
• if: ${{ !cancelled() }} chroni początkowe ! przed interpretacją jako tag YAML.
• Job-level if jest oceniane przed przydziałem runnera i rozwinięciem matrix.

Warunek może być czytelny także w kilku liniach

- name: Informacja dla autora PR
  if: >-
    ${{ github.event_name == 'pull_request'
        && github.base_ref == 'main'
        && github.event.pull_request.user.login != 'dependabot[bot]' }}
  run: echo "PR do main od autora innego niż Dependabot"

&& wymaga spełnienia wszystkich warunków; || daje alternatywę. Nawiasy pozwalają jawnie grupować warunki.

Najpierw sprawdzamy typ zdarzenia. W PR gałąź docelowa jest w base_ref, a autor w payloadzie PR-a.

Brak pola może oznaczać ''

env:
  TITLE: ${{ vars.REPORT_TITLE || 'Raport CI' }}
  SHA: ${{ github['sha'] }}

Brak właściwości w dostępnym kontekście to coś innego niż użycie niedozwolonego kontekstu albo błędna składnia expression.

Jeśli wartość jest obowiązkowa, waliduj ją zamiast ukrywać brak domyślnym tekstem.

Małe funkcje, konkretne zastosowania

contains dla listy szuka całego elementu, a dla tekstu podtekstu. Funkcje porównujące tekst ignorują wielkość liter.

Expressions — funkcje

fromJSON odtwarza typ wartości

Pusty lub niepoprawny JSON powoduje błąd parsowania. Poprawny JSON nadal wymaga sprawdzenia oczekiwanego kształtu i wartości.

Przyda się przy przenoszeniu listy komponentów do matrix. Nie serializujemy całego kontekstu github z tokenem do logów.

Brak pliku to pusty hash, nie wyjątek

# Fragment steps, po checkout
- run: test -f package-lock.json
- name: Odcisk zależności
  env:
    LOCK_HASH: ${{ hashFiles('package-lock.json') }}
  run: printf '%s\n' "$LOCK_HASH"

• hashFiles tworzy odcisk SHA-256 zestawu dopasowanych plików.
• Wzorce odnoszą się do GITHUB_WORKSPACE, nie do working-directory kroku.
• Brak dopasowań zwraca ''. Jeśli plik jest wymagany, osobny test -f wykrywa jego brak.

hashFiles — kontrakt

A && B || C nie zawsze wybiera B

Dlatego tekstowej flagi z env nie używamy jako samodzielnego warunku: porównujemy ją do 'true' albo świadomie parsujemy.

case() zachowuje także false i zero

env:
  RUN_KIND: >-
    ${{ case(
      github.event_name == 'pull_request',
      'PR',
      startsWith(github.ref, 'refs/tags/'),
      'tag',
      'branch'
    ) }}

Pary warunek–wynik i końcowy default dają nieparzystą liczbę argumentów, co najmniej 3. Po przekazaniu wyniku do env liczba lub boolean stają się tekstem.

Expressions — case

Warunek statusu zmienia dalszy przebieg

Zielony krok zbierania raportu nie cofa błędu testów. Awaria runnera może uniemożliwić nawet krok z always().

Status check functions

run: | zawiera zwykły skrypt

- name: Testy w wybranej konfiguracji
  shell: bash
  env:
    CONFIGURATION: ${{ inputs.configuration }}
  run: |
    case "$CONFIGURATION" in
      Debug|Release) ;;
      *) echo "::error::Nieznana konfiguracja"; exit 1 ;;
    esac
    dotnet test --configuration "$CONFIGURATION"

Actions przygotowuje env, a Bash odczytuje "$CONFIGURATION". Cudzysłów zachowuje wartość jako jeden argument.

Walidacja kontraktu jest częścią skryptu. SDK i kod repozytorium muszą być przygotowane we wcześniejszych krokach.

Ustal domyślną powłokę i katalog

defaults:
  run:
    shell: bash
    working-directory: backend

• Te wartości dotyczą kroków run w workflow.
• Ścieżka musi istnieć, np. po checkout.
• Nie zmieniają katalogu ani znaczenia inputów action wywołanej przez uses.

Powtarzającą się konfigurację zapisujemy raz, a lokalny wyjątek umieszczamy przy kroku, którego dotyczy.

Najbliższe ustawienie wygrywa

# Job nadpisuje poprzednie defaults
jobs:
  docs:
    runs-on: ubuntu-24.04
    defaults:
      run:
        working-directory: docs
    steps:
      - uses: actions/checkout@v7
      - run: pwd
      - run: pwd
        working-directory: .

Defaults i reguły nadpisywania

Log z tee nie może ukryć błędu

- name: Testy z kopią logu
  shell: bash
  run: |
    set -u
    dotnet test --configuration Release 2>&1 | tee tests.log
    echo "Testy zakończone sukcesem"

• Kod 0 oznacza sukces; niezerowy kod oznacza błąd.
• Jawne shell: bash dodaje -e i -o pipefail. Błąd testów nie ginie za udanym tee.
• set -u wykrywa użycie niezdefiniowanej zmiennej.
• -e ma wyjątki, np. w warunkach if i listach &&/||. Krytyczny warunek sprawdzaj jawnie.

Domyślna powłoka bez jawnego shell może używać innych opcji. Nie dodawaj || true do obowiązkowych testów.

Skrypt nie musi być Bashem

- uses: actions/setup-dotnet@v6
  with:
    dotnet-version: '10.x'
- name: Program C# jako krok
  shell: dotnet run --file {0}
  run: |
    var title = "Build";
    Console.WriteLine($"Length: {title.Length}");

// scripts/summary.cs
var title = "Build";
Console.WriteLine($"Length: {title.Length}");

dotnet run --file scripts/summary.cs

Program plikowy uruchamiany przez dotnet run to nie dotnet-script. Ten drugi jest osobnym narzędziem.

Custom shell · .NET — file-based apps

Powiąż ostrzeżenie z plikiem i linią

echo "::group::Sprawdzanie dokumentacji"
echo "::notice::Rozpoczęto analizę"
echo "::warning file=README.md,line=7::Brakuje opisu parametru"
echo "::endgroup::"

• ::notice::, ::warning:: i ::error:: tworzą adnotacje.
• Nazwa pliku i linia pomagają pokazać problem przy zmianie w PR.
• Samo ::error:: nie ustawia niezerowego exit code. Gdy problem ma zatrzymać job, skrypt musi również zgłosić błąd wykonania.

Workflow commands

Nie zmuszaj odbiorcy do czytania całego logu

{
  printf '## Sprawdzenie zmiany\n\n'
  printf '%s\n' '- Build zakończony.'
  printf '%s\n' '- Raport jest dostępny w artefaktach.'
} >> "$GITHUB_STEP_SUMMARY"

Runner składa treść podsumowania z kroków joba. Piszemy do pliku wskazanego przez zmienną środowiskową.

Podsumowanie opisuje wynik, ale nie zmienia statusu joba. W praktyce treść powinna wynikać z rzeczywiście wykonanych sprawdzeń.

Komentarz do PR przez API

if: >-
  ${{ github.event.pull_request.head.repo.full_name
      == github.repository }}
runs-on: ubuntu-24.04
permissions: {pull-requests: write}
steps:
  - uses: actions/github-script@v9
    with:
      script: |
        await github.rest.issues.createComment({
          ...context.repo,
          issue_number: context.issue.number,
          body: 'CI rozpoczęło sprawdzanie tej zmiany.'
        });

PR jest także issue. To zwykły komentarz, nie review linii. Rerun utworzy kolejny.

Klient API jest już przygotowany

if (!context.payload.pull_request) {
  core.setFailed('Oczekiwano zdarzenia PR');
  return;
}

await czeka na operację API. Wyjątek lub core.setFailed() oznacza błąd; samo return false nie oznacza czerwonego kroku.

github-script — udostępnione obiekty i wyniki

Czy zmienił się frontend?

const pr = context.payload.pull_request;
if (!pr) throw new Error('Oczekiwano PR');
const files = await github.paginate(github.rest.pulls.listFiles, {
  ...context.repo, pull_number: pr.number, per_page: 100
});
if (files.length >= 3000) throw new Error('Przekroczono limit tej reguły');
const paths = files.flatMap(file =>
  [file.filename, file.previous_filename].filter(Boolean));
require('node:fs').writeFileSync(
  'changed-paths.json', JSON.stringify(paths));
const frontend = paths.some(path => path.startsWith('frontend/'));
core.notice(`Zmiana frontendu: ${frontend}`);

paginate pobiera kolejne strony; endpoint nadal ma limit 3000 plików. Przy zmianie nazwy uwzględniamy również poprzednią ścieżkę.

Plik changed-paths.json wykorzystamy w sekcji przepływu danych. Błędu API nie zamieniamy w pustą listę i sukces.

REST — lista plików PR-a

Ten sam wynik, trzy narzędzia

printf 'Tryb: %s\n' \
  "$CONFIGURATION"

core.info('Tryb: ' +
  process.env.CONFIGURATION);

var mode = Environment
  .GetEnvironmentVariable(
    "CONFIGURATION");
Console.WriteLine(
  $"Tryb: {mode}");

Bash dobrze łączy CLI i pliki. github-script upraszcza GitHub API. .NET pozwala wykorzystać znany język i rozbudować testowalną logikę w osobnym pliku.

Małej komendy nie trzeba opakowywać w API klienta. Rosnący algorytm warto wydzielić z YAML do wersjonowanego skryptu.

Composite grupuje kroki backendu

name: Backend checks
description: Build and test
inputs:
  configuration:
    description: Build mode
    default: Release
runs:
  using: composite
  steps:
    - shell: bash
      env:
        CONFIGURATION: ${{ inputs.configuration }}
      run: |
        dotnet build --configuration "$CONFIGURATION"
        dotnet test --configuration "$CONFIGURATION"

Action korzysta z runnera i workspace callera. Zakładamy przygotowany kod .NET i SDK; każdy run w composite podaje własny shell.

Reusable dostarcza cały job backendu

on:
  workflow_call:
    inputs:
      configuration: {type: string, default: Release}
permissions: {contents: read}
jobs:
  backend:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-dotnet@v6
        with: {dotnet-version: '10.x'}
      - env: {CONFIGURATION: '${{ inputs.configuration }}'}
        run: |
          dotnet build --configuration "$CONFIGURATION"
          dotnet test --configuration "$CONFIGURATION"

Te same polecenia; teraz callee wybiera runnera i przygotowuje kod oraz SDK.

Composite w kroku. Reusable jako job.

runs-on: ubuntu-24.04
steps:
  - uses: actions/checkout@v7
  - uses: actions/setup-dotnet@v6
    with: {dotnet-version: '10.x'}
  - uses: ./.github/actions/backend
    with:
      configuration: Release

backend:
  uses: ./.github/workflows/backend.yml
  with:
    configuration: Release

Lokalna action musi być na dysku po checkout. Lokalny reusable workflow GitHub odczytuje z commita callera; checkout wewnątrz niego służy pracy z kodem aplikacji.

Action może dostarczyć własny skrypt

# Fragment runs.steps w composite
- shell: bash
  env:
    ACTION_DIR: ${{ github.action_path }}
    CONFIGURATION: ${{ inputs.configuration }}
  run: bash "$ACTION_DIR/backend.sh"

• github.action_path wskazuje katalog z dołączonym backend.sh.
• Zdalne uses: owner/repo/path@ref pobiera pakiet action i jego skrypty. Nie trzeba osobno checkoutować jej repozytorium.
• Checkout kodu aplikacji jest nadal potrzebny, jeśli skrypt ma go budować.
• Reusable workflow nie pobiera automatycznie wszystkich skryptów ze swojego repozytorium; domyślny checkout dotyczy repozytorium callera.

Composite współdzieli środowisko joba. Reusable ma własny kontrakt inputs i secrets; nie otrzymuje automatycznie env callera i nie może podnieść jego uprawnień tokena.

Env ma lokalny zakres

env:
  CONFIGURATION: Release
jobs:
  build:
    runs-on: ubuntu-24.04
    env:
      CONFIGURATION: Debug
    steps:
      - run: echo "$CONFIGURATION"
      - env:
          CONFIGURATION: Release
        run: echo "$CONFIGURATION"
      - run: echo "$CONFIGURATION"

Nowy krok to nowa powłoka

- name: Ustal katalog raportów
  run: echo "REPORT_DIR=reports" >> "$GITHUB_ENV"
- name: Przygotuj katalog
  run: |
    mkdir -p "$REPORT_DIR"
    printf 'Raporty: %s\n' "$REPORT_DIR"

• Zwykłe export w jednym run nie przechodzi do następnego procesu.
• GITHUB_ENV jest plikiem odczytywanym przez runnera po kroku.
• Zapisana wartość jest dostępna w następnych krokach tego joba, nie wstecznie w bieżącej powłoce.

To ustawienie środowiska. Dla nazwanego wyniku producenta użyjemy GITHUB_OUTPUT.

Lista ścieżek staje się planem pracy

jq -ce '
  def changed($root):
    any(.[]; startswith($root + "/")
      or startswith(".github/")
      or . == "global.json" or . == ".nvmrc");
  {frontend: changed("frontend"),
   backend: changed("backend")}
' changed-paths.json > plan.json

jq przetwarza JSON, nie wyszukuje przypadkowych fragmentów tekstu. Zmiana wspólnej konfiguracji uruchamia w tej regule oba komponenty.

{"frontend":true,"backend":false}

To przykładowy wynik dla zmiany tylko w frontend/. Reguły muszą uwzględniać również rzeczywiste współdzielone zależności projektu.

Producent publikuje nazwane wartości

- name: Opublikuj plan
  id: scan
  shell: bash
  run: |
    for part in frontend backend; do
      value=$(jq -r --arg p "$part" '.[$p]' plan.json)
      printf '%s=%s\n' "$part" "$value" >> "$GITHUB_OUTPUT"
    done
    echo "plan-path=plan.json" >> "$GITHUB_OUTPUT"

id: scan pozwala odczytać np. steps.scan.outputs.frontend. Każda linia nazwa=wartość dodaje output kroku.

Wyniki 'true' i 'false' są tekstami. plan-path jest ścieżką — sam output nie kopiuje pliku.

Run odbiera env. Action odbiera with.

- name: Odczytaj decyzję
  env:
    FRONTEND: ${{ steps.scan.outputs.frontend }}
  run: |
    printf 'Frontend: %s\n' "$FRONTEND"

- uses: actions/upload-artifact@v7
  with:
    name: component-plan
    path: ${{ steps.scan.outputs.plan-path }}
    if-no-files-found: error

Mapowanie jest jawne. Output nie tworzy automatycznie zmiennej Bash o tej samej nazwie.

Warunek wykonania może sprawdzić steps.scan.outputs.frontend == 'true'. Sam niepusty tekst 'false' byłby truthy.

Step → job → needs

outputs:
  frontend: ${{ steps.scan.outputs.frontend }}
  backend: ${{ steps.scan.outputs.backend }}

backend:
  needs: changes
  if: >-
    ${{ needs.changes.outputs.backend == 'true' }}
  uses: ./.github/workflows/backend.yml
  with:
    configuration: Release

Backend jest budowany tylko wtedy, gdy wymaga tego plan. needs udostępnia wyniki bezpośrednio wskazanych zależności, nie wszystkich jobs w workflow.

Passing job outputs

Decyzja planu ≠ wynik wykonania

summary:
  needs: [changes, backend]
  if: ${{ always() }}
  runs-on: ubuntu-24.04
  steps:
    - env:
        NEEDED: ${{ needs.changes.outputs.backend }}
        RESULT: ${{ needs.backend.result }}
      run: |
        printf 'Backend: potrzebny=%s, wynik=%s\n' \
          "$NEEDED" "$RESULT" >> "$GITHUB_STEP_SUMMARY"

true + success oznacza wykonaną pracę. false + skipped oznacza świadome pominięcie. true + failure wymaga uwagi.

Summary opisuje te stany. Osobny required gate będzie później egzekwował, które połączenia akceptujemy.

Composite wystawia wynik wewnętrznego kroku

outputs:
  frontend:
    description: Czy budować frontend
    value: ${{ steps.scan.outputs.frontend }}
  backend:
    description: Czy budować backend
    value: ${{ steps.scan.outputs.backend }}

- id: changed
  uses: ./.github/actions/changes
- env:
    FRONTEND: >-
      ${{ steps.changed.outputs.frontend }}
  run: printf '%s\n' "$FRONTEND"

Wewnętrzny step scan pozostaje wewnątrz action. Caller zna swoje id: changed i publiczne nazwy outputów.

Przenosimy do composite poznaną procedurę, nie zmieniamy reguły wykrywania ani tekstowego kontraktu wyniku.

Reusable mapuje job na wynik workflow

on:
  workflow_call:
    outputs:
      frontend:
        description: Czy budować frontend
        value: ${{ jobs.detect.outputs.frontend }}
      backend:
        description: Czy budować backend
        value: ${{ jobs.detect.outputs.backend }}

outputs:
  frontend: ${{ steps.scan.outputs.frontend }}
  backend: ${{ steps.scan.outputs.backend }}

Łańcuch to step → job → workflow. Kontekst jobs służy tutaj do wystawienia wyników reusable, nie do dowolnego odczytu w zwykłym callerze.

Caller czyta wynik pod własnym job ID

changes:
  uses: ./.github/workflows/changes.yml
backend:
  needs: changes
  if: ${{ needs.changes.outputs.backend == 'true' }}
  uses: ./.github/workflows/backend.yml
  with:
    configuration: Release

Caller nie zna wewnętrznego joba detect ani kroku scan. Zna interfejs wywołania changes.

Gdy output ma zasilić typowany input boolean, konwertujemy tekst przez fromJSON(...). Samo odczytanie outputu nie przywraca typu.

Artefakt przenosi rzeczywisty plik

- uses: actions/upload-artifact@v7
  with:
    name: component-plan
    path: plan.json
    if-no-files-found: error

- uses: actions/download-artifact@v8
  with:
    name: component-plan
    path: metadata
- run: jq . metadata/plan.json

Upload wiąże pliki z run. Download udostępnia je na innym runnerze. Ten sam mechanizm przenosi raporty testów, gotowy build albo PDF.

Nowy workflow ma własne uruchomienie

on:
  workflow_run:
    workflows: ['Component CI']
    types: [completed]
permissions: {actions: read}

Konsument nie otrzymuje needs poprzedniego run. Jego definicja musi istnieć na gałęzi domyślnej.

Wybierz run producenta, nie „ostatni plik”

read:
  if: >-
    ${{ github.event.workflow_run.conclusion == 'success'
        && github.event.workflow_run.head_repository.full_name
            == github.repository }}
  runs-on: ubuntu-24.04
  steps:
    - uses: actions/download-artifact@v8
      with:
        name: component-plan
        run-id: ${{ github.event.workflow_run.id }}
        github-token: ${{ secrets.GITHUB_TOKEN }}
        path: metadata
    - run: jq . metadata/plan.json

Pobieramy plan z run producenta. Token ma tylko actions: read.

Artefakt to dane, nie kod. Nie wykonuj go z większymi uprawnieniami konsumenta.

workflow_run — kontekst i bezpieczeństwo

Dwa systemy × dwie wersje = cztery jobs

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-24.04, windows-latest]
    node: ['24', '26']
steps:
  - uses: actions/setup-node@v7
    with:
      node-version: ${{ matrix.node }}
      package-manager-cache: false
  - run: node --version

Usuń wyjątek. Dodaj wariant.

strategy:
  matrix:
    os: [ubuntu-24.04, windows-latest]
    node: ['24', '26']
    exclude:
      - os: windows-latest
        node: '26'
    include:
      - os: macos-latest
        node: '24'

Koszt i reakcję na błąd ustawiamy osobno

strategy:
  fail-fast: false
  max-parallel: 2
  matrix:
    node: ['22', '24', '26']

continue-on-error ma inną rolę: zmienia traktowanie niepowodzenia. Nie włączamy go zamiast naprawy wymaganych testów.

Plan dostarcza listę wariantów

components=$(jq -c \
  'to_entries | map(select(.value == true) | .key)' plan.json)
printf 'components=%s\n' "$components" >> "$GITHUB_OUTPUT"

# Dodaj do outputs joba changes
outputs:
  components: ${{ steps.scan.outputs.components }}

Dla obu zmienionych komponentów output zawiera tekst ["frontend","backend"]. Dla samej dokumentacji będzie to [].

To wciąż ten sam plan, a nie druga, niezależna reguła wykrywania zmian.

fromJSON zamienia output w matrix

selected:
  needs: changes
  if: ${{ needs.changes.outputs.components != '[]' }}
  runs-on: ubuntu-24.04
  strategy:
    matrix:
      component: ${{ fromJSON(needs.changes.outputs.components) }}
  steps:
    - env:
        COMPONENT: ${{ matrix.component }}
      run: |
        printf 'Wybrany komponent: %s\n' "$COMPONENT"

Job-level if jest oceniane przed matrix. Pusta lista świadomie pomija job; brak lub niepoprawny JSON powinien ujawnić błąd producenta, nie wybrać „wszystko” albo „nic” po cichu.

Wariant może następnie wywołać właściwą procedurę builda. Matrix nie zastępuje przygotowania jej narzędzi.

Deklaracja ≠ rozwiązany zestaw zależności

{
  "dependencies": {
    "is-number": "^7.0.0"
  }
}

{
  "packages": {
    "node_modules/is-number": {
      "version": "7.0.0"
    }
  }
}

To wycinki. Pełny lockfile zapisuje także graf zależności przechodnich i dane potrzebne do odtworzenia pobrań, np. integralność pakietów.

Manifest i lockfile aktualizujemy świadomie razem. CI ma odtwarzać ustalony zestaw, a nie samoczynnie „naprawiać” jego wersje.

Lockfile nie przypina SDK

{
  "sdk": {
    "version": "10.0.401",
    "rollForward": "disable"
  }
}

- uses: actions/setup-dotnet@v6
  with:
    global-json-file: global.json
- uses: actions/setup-node@v7
  with:
    node-version-file: .nvmrc
    package-manager-cache: false

Najpierw checkout. Wcześniejsze 10.x było prostym przykładem wyboru rodziny SDK; powtarzalny projekt potrzebuje świadomej polityki dokładnych wersji i aktualizacji.

Ten sam commit to dopiero początek

• Określ wersje narzędzi, zależności i konfigurację builda.
• Wymagaj zgodności manifestu z lockfile; używaj trybu instalacji respektującego blokadę.
• Kontroluj dodatkowe wejścia: dane testowe, zmienne i usługi zewnętrzne.
• Utrzymuj możliwość zbudowania projektu bez cache i bez stanu poprzedniego runnera.
• Powtarzalne wykonanie testów nie gwarantuje jeszcze identycznych bajtów artefaktu — np. timestamp też może być wejściem.

Cache optymalizuje koszt odtworzenia tych wejść. Nie określa, które wersje powinny zostać użyte.

Cache można stracić. Wynik trzeba przekazać.

Odzyskanie cache nie zastępuje instalacji, kompilacji ani testów. Nie przechowujemy w nim sekretów.

Klucz opisuje zgodność danych

- id: packages
  uses: actions/cache@v6
  env:
    PREFIX: ${{ runner.os }}-${{ runner.arch }}-npm-v1
  with:
    path: ~/.npm
    key: ${{ env.PREFIX }}-${{ hashFiles('package-lock.json') }}
    restore-keys: ${{ env.PREFIX }}-

• key: system, architektura, rodzaj danych i hash zależności.
• restore-keys: zgodny prefiks zapasowy, gdy dokładnego wpisu nie ma.
• Wpis cache nie jest aktualizowany w miejscu. Inne dane wymagają nowego klucza.

Tu cache zawiera pobrania npm, nie node_modules. Dla binariów zgodność może wymagać również wersji runtime, ABI i innych wejść builda.

Hit zmienia koszt, nie kryteria sukcesu

Standardowa action cache zapisuje nowy wpis w fazie post-job po sukcesie, gdy nie było exact hit i zapis jest dozwolony.

actions/cache — output cache-hit

Setup action może obsłużyć cache zależności

- uses: actions/setup-node@v7
  with:
    node-version-file: .nvmrc
    cache: npm
    cache-dependency-path: package-lock.json
- run: npm ci

- uses: actions/setup-dotnet@v6
  with:
    global-json-file: global.json
    cache: true
    cache-dependency-path: '**/packages.lock.json'

W obu przypadkach wymagane są odpowiednie lockfiles. Setup cache nie jest poleceniem odtworzenia zależności aplikacji.

Wybierz setup action albo osobne actions/cache dla tego samego katalogu. Nie dodawaj dwóch konkurujących mechanizmów bez potrzeby.

setup-node — cache · setup-dotnet — cache

Status i check run to różne modele

Actions wystawia checks dla jobs, nie osobny check dla każdego kroku. Nazwa wyniku i SHA są ważniejsze niż sam zielony kolor.

GitHub — status checks

Reguła wybiera wymagany wynik

• Ruleset może wymagać PR-a, review i określonych checks.
• Wybieramy rzeczywistą nazwę checka i, jeśli potrzeba, aplikację źródłową.
• Nowy commit wymaga wyniku dla właściwego SHA. Tryb strict wymaga również aktualności względem bazy.
• Zmiana nazwy joba może wymagać zmiany reguły. Testujemy ochronę kontem bez uprawnienia bypass.

neutral i skipped mogą spełnić wymagany check. Brak całego workflow po filtrze może pozostawić Expected / Pending — to inna sytuacja niż pominięty job.

Rulesets

Zmiany mogą uruchomić zero, jeden lub dwa workflows

on:
  pull_request:
    branches: [main]
    paths:
      - 'frontend/**'
      - '.nvmrc'
      - '.github/**'

on:
  pull_request:
    branches: [main]
    paths:
      - 'backend/**'
      - 'global.json'
      - '.github/**'

branches i paths muszą być spełnione jednocześnie. Zmiana wspólnej konfiguracji może uruchomić oba CI; zmiana samej dokumentacji — żadnego.

Filtr jest decyzją o tym, czy powstanie run. Trzeba ją uzgodnić z polityką wymaganych checks.

Dwa workflows, jedna wymagana nazwa

jobs:
  required:
    name: required
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Frontend"

jobs:
  required:
    name: required
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Backend"

Ruleset wybiera nazwę checka. Tutaj ustala ją name: required, nie samo id joba.

W badanej konfiguracji przeszły warianty z jednym sukcesem albo dwoma sukcesami. Wspólna nazwa nie oznaczała „dowolny zielony wystarczy”, gdy drugi check nadal trwał lub zakończył się błędem.

Jeden udany run może wystarczyć

Brak uruchomienia nie tworzy zielonego wyniku. Żeby uniknąć tej pułapki, można zapewnić zawsze obecny, lekki gate.

Końcowe wyniki potwierdzono aktywnym rulesetem: nazwa required, źródło GitHub Actions, brak bypass także dla administratorów. Klasyczna ochrona gałęzi była wyłączona.

Dwa uruchomienia: czekamy na oba wyniki

Wyniki końcowe potwierdzono także aktywnym rulesetem. To obserwacja, nie gwarancja API dla dowolnej konfiguracji: znaczenie mają filtry, nazwa, źródło checka i SHA.

GitHub zaleca unikalne nazwy jobs między workflows

Opcjonalna praca. Jeden stały gate.

• Workflow nie ma filtra paths na poziomie on; powstaje dla każdego PR-a.
• Poznana procedura changes publikuje plan. Poszczególne jobs korzystają z if.
• Jeden unikalny check Required CI sprawdza sukces planowania i wyniki potrzebnych komponentów.
• Ruleset wymaga gate, a nie nazw warunkowo pomijanych workflow.

Gate sprawdza decyzję i wykonanie

required:
  name: Required CI
  needs: [changes, frontend, backend]
  if: ${{ always() }}
  runs-on: ubuntu-24.04
  permissions: {contents: read}
  steps:
    - uses: actions/checkout@v7
    - env:
        RESULTS: ${{ toJSON(needs) }}
      run: node .github/scripts/required.cjs

always() pozwala ocenić zależności także po ich błędzie. Wymagamy ponadto needs.changes.result == 'success'.

Błędny lub brakujący wynik nie przechodzi

const results = JSON.parse(process.env.RESULTS);
if (results.changes?.result !== 'success') {
  throw new Error('Nie udało się ustalić planu');
}
for (const name of ['frontend', 'backend']) {
  const needed = results.changes.outputs?.[name];
  const result = results[name]?.result;
  const accepted = (needed === 'true' && result === 'success')
    || (needed === 'false' && result === 'skipped');
  if (!accepted) throw new Error(`Niespełniony warunek: ${name}`);
}

To jawna polityka: potrzebna praca musi zakończyć się sukcesem, a niepotrzebna może być pominięta.

Jak każdy element CI, skrypt gate i konfigurację workflow chronimy review. Zielony gate nie pomoże, jeśli PR może dowolnie usunąć jego kontrole.

Build nie potrzebuje prawa publikacji

• Build i testy dostają odczyt kodu, nie domyślne write-all.
• Zapis przez API wydzielamy do joba, który go rzeczywiście potrzebuje.
• Nie przekazujemy sekretów produkcyjnych do testów z tymczasową bazą.
• Sekrety nie trafiają do Git, outputs, artefaktów ani cache. Maskowanie logów jest tylko dodatkową ochroną.
• Fork PR i kod zależności traktujemy jako niezaufane. Zgoda na uruchomienie nie czyni kodu bezpiecznym.

Reusable workflow nie może podnieść uprawnień tokena callera. Sekrety przekazuje się przez jawny interfejs; samo env nie tworzy takiego kontraktu.

Nie interpoluj danych do źródła skryptu

- name: Sprawdź tytuł PR
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  shell: bash
  run: |
    test -n "$PR_TITLE"
    printf 'Długość tytułu: %s\n' "${#PR_TITLE}"

• Expression w env przekazuje dane, a nie fragment kodu Bash.
• W github-script użyj process.env.PR_TITLE albo bezpośredniego odczytu payloadu context.
• Nie wykonuj danych przez eval. Walidacja tekstu nie zastępuje oceny zaufania do kodu PR-a.

GitHub — ograniczanie script injection · zizmor — wykrywanie niebezpiecznej interpolacji (template-injection)

Przypnij kod. Zaplanuj aktualizację.

- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1

Ruchomy major tag może istnieć obok immutable release, jeśli sam nie jest z takim wydaniem związany. Niektórzy autorzy z niego rezygnują; politykę i aktualizacje sprawdzamy u autora action.

Pinning third-party actions · Immutable releases · Wydania i ruchome tagi actions

Popularna action też może zostać przejęta

• W incydencie tj-actions/changed-files zmieniono kod osiągalny przez istniejące tagi.
• Złośliwa wersja ujawniała w logach dane z pamięci runnera, w tym potencjalnie sekrety.
• Publiczne logi mogły uczynić wyciek dostępny dla innych osób.
• Wniosek: ogranicz uprawnienia, przypinaj zweryfikowane rewizje, oceniaj zależności i reaguj na komunikaty bezpieczeństwa.

Wykrywanie zmienionych plików jest przydatne, ale dodatkowa action to również dodatkowy kod do zaufania. Pokazany klient API pozwala zobaczyć samą regułę wprost.

GitHub Advisory — CVE-2025-30066, tj-actions/changed-files

Workflow również wymaga utrzymania

actionlint
zizmor .github/workflows
pnpm dlx pin-github-action@3.5.2 \
  .github/workflows --comment ' pin@{ref}'

zizmor · Dependabot dla Actions · Renovate — github-actions · pin-github-action 3.5.2

Promotor potrzebuje PDF z konkretnej rewizji

README projektu opisuje środowisko Debian z texlive-full i komendę make. W CI jawnie wybieramy tryb PDF i zatrzymanie po błędzie.

Możesz sforkować szablon na GitHubie, zachować atrybucję i napisać własną treść. Brak jawnej licencji nie daje automatycznie prawa do redystrybucji przykładowego tekstu, logo ani innych cudzych materiałów.

pjatk_latex · Omawiana wersja e660b9e · Makefile · latexmk

Kompiluj bez prawa publikacji

steps:
  - uses: actions/checkout@v7
    with:
      ref: ${{ github.event.pull_request.head.sha || github.sha }}
  - name: Przygotuj TeX
    shell: bash
    run: |
      sudo apt-get update
      sudo apt-get install -y \
        latexmk biber texlive-latex-extra texlive-bibtex-extra \
        texlive-fonts-recommended texlive-lang-polish texlive-science
  - name: Zbuduj PDF
    shell: bash
    run: |
      latexmk -norc -pdf -interaction=nonstopmode \
        -halt-on-error -file-line-error -no-shell-escape engineer.tex
      test -s engineer.pdf

PR: HEAD autora. Push: SHA zdarzenia. Późniejszy tag musi wskazywać tę samą rewizję.

PDF do pobrania. Log do diagnozy.

- uses: actions/upload-artifact@v7
  with:
    name: thesis-pdf
    path: engineer.pdf
    if-no-files-found: error

- if: ${{ !cancelled() }}
  uses: actions/upload-artifact@v7
  with:
    name: latex-log
    path: engineer.log
    if-no-files-found: warn

Udany build bez PDF jest błędem kontraktu. Log próbujemy zachować także po błędzie kompilacji; jeśli błąd wystąpił wcześniej, plik może jeszcze nie istnieć.

Podgląd PR-a i wydanie z main

Workflow najpierw trafia na main. Nie podmieniamy docelowego SHA, żeby obejść ograniczenie API. To publikacja dokumentu, nie deployment aplikacji.

Release API — uprawnienia dla zmian workflow

Zmiana workflow → tylko artefakt

runs-on: ubuntu-24.04
permissions: {pull-requests: read}
outputs:
  workflow-edits: ${{ steps.files.outputs.workflow-edits }}
steps:
  - id: files
    uses: actions/github-script@v9
    with:
      script: |
        const pr = context.payload.pull_request;
        const files = pr ? await github.paginate(github.rest.pulls.listFiles,
          { ...context.repo, pull_number: pr.number, per_page: 100 }) : [];
        if (files.length >= 3000) throw new Error('Niekompletna lista plików PR');
        const paths = files.flatMap(f => [f.filename, f.previous_filename]);
        const edited = paths.some(p => p?.startsWith('.github/workflows/'));
        core.setOutput('workflow-edits', edited);
        if (edited) core.notice('Zmiana workflow: PDF pozostaje artefaktem.');

Prawo zapisu tylko w jobie publikacji

publish:
  needs: [pdf, policy]
  if: >-
    ${{ needs.policy.outputs.workflow-edits == 'false'
        && ((github.event_name == 'push' && github.ref == 'refs/heads/main')
            || (github.event_name == 'pull_request'
                && github.event.pull_request.head.repo.full_name == github.repository
                && github.event.pull_request.user.login != 'dependabot[bot]')) }}
  runs-on: ubuntu-24.04
  permissions: {contents: write}
  steps:
    - uses: actions/download-artifact@v8
      with:
        name: thesis-pdf
        path: release-files

Po sukcesie pdf i policy pobieramy gotowy plik. Nie wykonujemy kodu PR-a w jobie z prawem zapisu.

Następne kroki rozróżnią prerelease PR i zwykły release main.

Prerelease: PDF do review

- if: ${{ github.event_name == 'pull_request' }}
  shell: bash
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    GH_REPO: ${{ github.repository }}
    PR_NUMBER: ${{ github.event.number }}
    SOURCE_SHA: ${{ github.event.pull_request.head.sha }}
  run: |
    tag="pr-${PR_NUMBER}-run-${GITHUB_RUN_ID}-a${GITHUB_RUN_ATTEMPT}"
    gh release create "$tag" release-files/engineer.pdf \
      --prerelease --latest=false --target "$SOURCE_SHA" \
      --title "PDF PR #$PR_NUMBER" \
      --notes "Wersja do review; commit $SOURCE_SHA."

Unikalny tag dla run i próby nie nadpisuje poprzedniego wydania. GH_REPO wskazuje repozytorium bez potrzeby checkout.

Release: PDF z zaakceptowanego main

- if: ${{ github.event_name == 'push' }}
  shell: bash
  env:
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    GH_REPO: ${{ github.repository }}
    SOURCE_SHA: ${{ github.sha }}
  run: |
    tag="pdf-main-${GITHUB_RUN_ID}-a${GITHUB_RUN_ATTEMPT}"
    gh release create "$tag" release-files/engineer.pdf \
      --latest --target "$SOURCE_SHA" \
      --title "PDF z main" \
      --notes "Wydanie dokumentu; commit $SOURCE_SHA."

Nie ustawiamy --prerelease. Release utworzony przez GITHUB_TOKEN nie uruchomi kolejnego workflow przez on: release.

gh release create — target, prerelease i latest

Brak błędu kompilacji ≠ gotowa praca

Jeśli zespół wymaga braku określonych ostrzeżeń, dopisuje jawną kontrolę logu. Ocena treści naukowej nadal należy do człowieka.

Automatyzuj sprawdzalne twierdzenia

W każdym przypadku ustalamy: wejście → polecenie → warunek błędu → wynik → odbiorca.

CI skraca pętlę. Zespół zamyka pętlę.

1. Co sprawdziliśmy? Wskaż rewizję, środowisko i rzeczywisty zakres testów.
2. Jak przenosimy wynik? Odróżnij output, env, artefakt i cache.
3. Dlaczego merge jest dozwolony? Wskaż wymagany check, jego kontrakt i uprawnienia procesu.

W laboratorium zastosujemy te mechanizmy do aplikacji. Wykład pozostaje mapą pojęć, nie gotowym rozwiązaniem zadania.