Automatyczne wersjonowanie motywu WordPress z Semantic Release

Każdy, kto pracuje z motywami WordPress, zna ten ból: ręczne edytowanie wersji w style.css, pisanie changelogów, pamiętanie o wszystkich plikach przy mergowaniu. A co jeśli powiem Ci, że asystent AI może postawić cały pipeline i potem obsłużyć Twoje commity krótkimi komendami?

Spis treści

Problem z wersjonowaniem w WordPress

WordPress trzyma wersję motywu w komentarzu CSS w pliku style.css, a nie w package.json jak nowoczesne projekty. Standardowe narzędzia do wersjonowania nie działają out-of-the-box.

Kluczowy insight: Mostem między WordPressem a Semantic Release jest jedna komenda sed, która przepisuje linię Version: w style.css podczas każdego release’u. Cała reszta — analiza commitów, generowanie changelogów, GitHub Releases — działa standardowo.

Rozwiązaniem jest Semantic Release z odpowiednią konfiguracją — wdrożony przez skill Claude Code, który ogarnia całe okablowanie.

Jednorazowy setup: aktywacja skilla

Zamiast ręcznie tworzyć konfiguracje, workflowy i skrypty, odpalasz jedną komendę w Claude Code:

/wordpress-theme-semantic-github-deployment

Skill automatycznie wykrywa środowisko — czyta nagłówek style.css, git remote, nazwę brancha, istniejący package.json — i przeprowadza Cię przez krótki wywiad, w którym wybierasz ficzery.

Co zostaje wygenerowane

Opcjonalne ficzery (wybierane podczas wywiadu)

Budujesz plugin zamiast motywu? Jest odpowiedni skill: /wordpress-plugin-semantic-github-deployment — ten sam pipeline, dostosowany do nagłówków plików pluginów.

Codzienna praca: trzy komendy

Gdy pipeline stoi, Twoja codzienna praca sprowadza się do trzech komend z zestawu skilli commit-push-pr:

/sco — Semantic Commit

Analizuje diff, wybiera odpowiedni typ i scope, staguje konkretne pliki i commituje:

feat(search): add fuzzy matching helper
fix(cart): correct tax calculation to include base price
refactor(admin): extract settings into dedicated options handler

Staguje pliki po nazwie — nigdy git add .. Żadnych sekretów w commitach. Tryb rozkazujący, max 72 znaki.

/spr — Branch → Commit → Push → PR

Pełny flow w jednej komendzie. Tworzy semantyczną nazwę brancha, commituje, pushuje z upstream tracking i otwiera PR z poprawnym tytułem:

Branch:  feat/add-search-filter
Commit:  feat(search): add result filtering
PR:      feat(search): add result filtering

Body PR-a zawiera podsumowanie i typ wpływu na wersję.

/spu — Push

Pushuje aktualny branch do origin z upstream tracking. Tyle.

Dlaczego tytuł PR to wszystko

Przy Squash & Merge GitHub spłaszcza Twój branch do jednego commita, używając tytułu PR jako wiadomości. Semantic Release czyta tę wiadomość, żeby zdecydować o bump wersji. Tytuł PR to jedyna rzecz, która determinuje numer następnej wersji.

Konwencja Conventional Commits

Pełny flow

sequenceDiagram
    participant Dev as Deweloper
    participant CC as Claude Code
    participant GH as GitHub
    participant GHA as GitHub Actions
    participant Rel as Release

    Dev->>CC: /spr (lub /sco + /spu)
    CC->>CC: Analiza diffa → typ i scope
    CC->>GH: Branch, commit, push, PR
    GH->>GH: PR Lint waliduje tytuł ✓
    Dev->>GH: Squash & Merge
    GH->>GHA: Trigger release workflow
    GHA->>GHA: Bump wersji w style.css
    GHA->>GHA: Update CHANGELOG.md
    GHA->>Rel: Publikacja v1.2.0 + ZIP

Po setupie: ustawienia GitHub

Po wygenerowaniu plików przez skill, skonfiguruj repozytorium:

1. Tylko squash merge — Settings → General → Pull Requests: włącz “Allow squash merging” (domyślnie PR title), wyłącz merge commits i rebase merging.
2. Branch protection — Settings → Branches: wymagaj statusu “Validate PR title” przed merge’em.

Gotcha przy pierwszym release: Na niektórych repo pierwszy squash-merge może nie odpalić workflow Release. Jeśli się nie odpali, pusha pustego commita: git commit --allow-empty -m "ci: trigger release workflow" && git push. Kolejne merge’e działają normalnie.

Podsumowanie

Jeden skill stawia pipeline. Trzy komendy obsługują resztę:

/wordpress-theme-semantic-github-deployment  →  jednorazowy setup
/sco                                         →  semantic commit
/spr                                         →  branch + commit + push + PR
/spu                                         →  push

Twój zespół skupia się na kodzie. Roboty ogarniają wersjonowanie, changelogi i release’y.

Przydatne linki

• wordpress-theme-semantic-github-deployment — skill Claude Code do stawiania pipeline’u release
• commit-push-pr — skille Claude Code do commitów, pushy i PR-ów
• Semantic Release — dokumentacja
• Conventional Commits — specyfikacja
• action-semantic-pull-request
• GitHub Actions — dokumentacja