Dostarczanie zmian i diagnostyka pipeline
Zaprojektujesz kontrolowane przejście od PR i testów do kandydata wydania oraz zdiagnozujesz błąd workflow.
1. Krótka teoria
Praca nad zmianą zaczyna się na osobnej gałęzi. PR uruchamia CI, a jego wynik jest bramką przed włączeniem kodu do main. Po zatwierdzeniu można zbudować wersjonowany obraz i zachować identyfikator commita oraz wynik testów. Artifact jest wynikiem workflow; nie powinien zawierać sekretów. Etap dostarczania może przygotować obraz i instrukcję wydania, a właściwy deployment wymaga osobnego joba zależnego od testów, jawnego wyzwalacza i kontroli środowiska. needs: checks wiąże job z wynikiem jakości. workflow_dispatch pozwala na ręczne uruchomienie; reguły środowiska GitHub mogą wymagać zatwierdzenia przed użyciem sekretów. Token GITHUB_TOKEN powinien mieć minimalne uprawnienia, a poświadczenia zewnętrzne należy pobierać z kontrolowanych sekretów lub krótkotrwałej tożsamości. Nie przekazuj ich do joba testującego nieufny PR. Przy niepowodzeniu znajdź pierwszą błędną fazę: trigger, runner, checkout, instalacja, test, build albo uprawnienia. Czytaj log konkretnego kroku i porównaj komendy z lokalnym wynikiem. Powtórne uruchomienie bez diagnozy może ukryć niestabilny test; wynik, commit i przyczynę zapisz przed kolejną próbą.
2. Przykłady komend
git status --short
Sprawdza stan zmian przed przygotowaniem PR.
$ git status --short
git rev-parse HEAD
Zapisuje dokładny commit związany z wynikiem CI.
$ git rev-parse HEAD
gh run list --limit 5
Pokazuje najnowsze uruchomienia workflow.
$ gh run list --limit 5
gh run view --log-failed
Pozwala wybrać uruchomienie i odczytać log nieudanych kroków.
$ gh run view --log-failed
gh run view
Otwiera szczegóły wybranego uruchomienia w CLI.
$ gh run view
needs: checks
Fragment YAML uzależniający job dostarczania od pozytywnego wyniku kontroli.
jobs:
checks:
runs-on: ubuntu-latest
steps:
- run: pytest
delivery:
needs: checks
runs-on: ubuntu-latest
steps:
- run: echo 'Kontrole zakończone'3. Zadanie praktyczne
orders-api drogę zmiany: branch, PR, wynik Ruff i pytest, budowa obrazu, identyfikator commita, kontrolowany job dostarczenia oraz osobna decyzja o wdrożeniu. W ćwiczeniowym YAML dodaj needs: checks i wyzwalacz workflow_dispatch dla etapu wymagającego decyzji operatora; nie dodawaj prawdziwego wdrożenia. Na przygotowanym nieudanym uruchomieniu znajdź pierwszy błędny krok przez gh run view --log-failed, zapisz przyczynę i lokalną komendę do odtworzenia problemu.
4. Typowe błędy
- Udzielanie sekretów jobowi uruchamianemu dla nieufnego PR.
- Uruchamianie joba dostarczenia bez zależności od kontroli jakości.
- Mylenie artifactu lub obrazu z już wykonanym wdrożeniem.
- Dawanie GITHUB_TOKEN szerokich praw zapisu bez uzasadnienia.
- Ponawianie nieudanego pipeline bez analizy pierwszego błędnego kroku.
- Brak zapisu commita odpowiadającego przygotowanemu wydaniu.
5. Podsumowanie
CI sprawdza PR, a późniejszy etap może przygotować wersjonowany wynik do dostarczenia. Job zależny od testów, kontrolowane sekrety i jawna decyzja ograniczają ryzyko wdrożenia. Diagnoza zaczyna się od pierwszego błędnego kroku i jego logu.