Az 1.2-es verzió a Gutenberg fejlesztési folyamatát is egy alkalmazásba szervezi
A WordPress fejlesztői közösségének szeptember 25-i bejelentése szerint megjelent a WordPress Contributor Toolkit 1.2.0, amely a Core mellett már a Gutenberghez készülő hozzájárulások teljes munkafolyamatát is támogatja a környezet létrehozásától a pull request beküldéséig. Bár a két fejlesztési irány ugyanazt az alkalmazásfelületet használja, a projekt létrehozásakor választani kell közöttük, és ez a beállítás később nem módosítható.
A WordPress Core oldalán közzétett bejelentés (új ablakban nyílik meg) szerint az eszköz eredetileg az első hozzájárulást megelőző technikai akadályok csökkentésére készült, különösen a közös fejlesztői események, a Contributor Day-ek résztvevőinek. Az új kiadás a blokkszerkesztő fejlesztéséhez is végigvezetett folyamatot ad, miközben az 1.1-ben bevezetett Git-kezelés a tapasztalt közreműködők megszokott parancssoros munkájával is együtt használható.
Az 1.2-es kiadás a Core után a Gutenberg teljes munkafolyamatát is lefedi
A Toolkit első változata a WordPress-fejlesztői környezet összeállítását egyszerűsítette. Az 1.0 már a Core-hozzájárulás további lépéseit is beemelte az alkalmazásba: a Trac hibakövetőben szereplő jegy feldolgozásától a hozzá kapcsolt javítás tesztelésén át a saját módosítás beküldéséig.
A most megjelent 1.2.0 (új ablakban nyílik meg) ugyanezt az utat nyitja meg a Gutenberg számára. A fejlesztő egy helyi tesztoldalhoz kapcsolhatja a GitHubon nyilvántartott feladatot, kipróbálhatja a már elkészült javításokat, majd ellenőrizheti és beküldheti saját változtatásait.
A két terület közötti különbséget az alkalmazás a feladatkezelésben is követi. Core-projektnél Trac-jegy, Gutenberg-projektnél GitHub issue kapcsolódik a munkához; utóbbinál a beküldés célja egy GitHub pull request, vagyis a módosítások felülvizsgálatára és beolvasztására szolgáló kérelem.
A Gutenberg-környezet előkészítése automatizált, az újrafordítást külön kell elindítani
A Create a site műveletnél a célmappa mellett azt is meg kell adni, hogy a helyi oldal a WordPress Core vagy a Gutenberg fejlesztését szolgálja. Az alapértelmezés a Core, a választás pedig meghatározza a klónozott kódtárat, a buildfolyamatát és a futtatás módját.
Gutenberg esetén a Toolkit klónozza a blokkszerkesztő kódtárát, a mellékelt npm 11 segítségével telepíti a függőségeket, majd elkészíti a csomagok buildjét. A beállítás egyetlen összefüggő folyamatként fut le; utána a Start dev server gombbal indítható a tesztkörnyezet.
A futtatási dokumentáció (új ablakban nyílik meg) szerint ilyenkor egy alap WordPress-példány indul Playgroundban, amelybe a helyi Gutenberg-munkapéldány már aktivált bővítményként kerül be. A bejegyzések, a beállítások és a feltöltött fájlok megmaradnak a szerver leállítása és az alkalmazás újraindítása után is.
A kezdeti teljes build miatt a fejlesztői szerver a bejelentés szerint másodpercek alatt elindul. A fájlmentések utáni automatikus újrafordítás azonban külön művelet: a Start build watch a Gutenberg saját npm run dev parancsát indítja el, amely először mindent újraépít, majd a további mentéseket követi.
Ez a gyakorlatban két külön állapotot jelent. A már elindított tesztoldalon kipróbálható az előkészítéskor lefordított kód, de a szerkesztőben elmentett további változtatások automatikus fordításához a figyelőfolyamatnak is futnia kell.
A GitHub-feladatok és a kipróbált javítások külön ágakon maradnak
A Gutenberg-oldal GitHub issue kártyáján a feladat száma vagy URL-je adható meg. A hozzárendelés után (új ablakban nyílik meg) az issue saját Git-ágat kap, így a különböző feladatokon végzett munka elkülönül.
Az alkalmazásból váltani lehet az issue-k között, félretehető a még be nem fejezett módosítás, és a feladat ága az aktuális fő fejlesztési ághoz is hozzáigazítható. A kapcsolt issue mellett megjelennek az ahhoz tartozó pull requestek és azok állapotai.
Az Apply… gomb először megmutatja, mely fájlokat érinti a kiválasztott PR. Ezután a Toolkit külön ágra váltva tölti be a javítást, az eredeti szerző commitjaival együtt; a Revert this PR művelet visszaállítja a fejlesztő saját munkáját.
Ha például egy hibajegyhez már tartozik javítási javaslat, a közreműködő előbb azt tesztelheti, majd visszatérhet saját változtatásaihoz. A kipróbált megoldás commitjai külön ágon vizsgálhatók, ezért látható marad, pontosan melyik változat került tesztelésre.
A beküldés a teljes kódkülönbség ellenőrzésével indul
A Review & submit changes képernyő a teljes diffet, vagyis a fájlokon végrehajtott változtatások tételes különbségét mutatja. Gutenberg-projektnél innen az Open a pull request lehetőség vezet a beküldéshez.
A GitHub-beküldés dokumentált menete (új ablakban nyílik meg) az eszközkódos, úgynevezett device flow azonosítást használja. A Toolkit a közreműködő fiókjába forkolja a WordPress/gutenberg kódtárat, feltölti a munkát tartalmazó ágat, majd az API-n keresztül megnyitja a pull requestet.
A hitelesítési adat csak a memóriában marad meg, és az alkalmazás bezárásakor eltűnik. Ez az azonosítás tárolására vonatkozik; a már beküldött PR természetesen a GitHubon kezelhető tovább.
Az űrlapon cím és a felülvizsgálóknak szánt leírás adható meg. A bejelentés külön kitér a tesztelési lépésekre: a leírásnak követhetővé kell tennie, hogyan reprodukálható az ellenőrzés, és milyen eredmény várható.
A kapcsolódást a feladathoz az automatikusan hozzáadott Fixes #N sor biztosítja. Emiatt a pull request a megnyitás után megjelenik az issue mellett, külön összekapcsoló bejegyzés nélkül.
A mellékelt Git a megszokott verziókezelési működést biztosítja
A mostani kiadás hátterének jelentős változása már az 1.1-ben megtörtént: a Toolkit az 1.0 JavaScript-alapú Git-újraimplementációja helyett valódi Gitet szállít, a GitHub Desktop által is használt megoldásra építve. Ez a számítógép Git-beállításaitól függetlenül működik, és nem igényel előzetesen telepített Gitet.
Az alkalmazás műveletei így tényleges Git-parancsoknak felelnek meg:
| Művelet a Toolkitben | Verziókezelési művelet |
|---|---|
| Új helyi projekt létrehozása | A kódtár klónozása |
| Feladat hozzárendelése | Külön ág létrehozása |
| Patch alkalmazása | git apply |
| Pull request kipróbálása | Fetch és checkout |
| A fő fejlesztési ág frissítése | Fetch és merge |
Ennek a javítások ellenőrzésénél is van következménye. A patch illeszkedését a Git kezeli; sikertelen alkalmazáskor a Toolkit megjelöli a problémás kódrészleteket, és változatlanul hagyja a munkapéldányt.
Az ágak elnevezése követhető: a Core-jegyekhez ticket/N, a Gutenberg-feladatokhoz issue/N, a tesztelt pull requestekhez pr/N tartozik. Az utóbbiakon az eredeti szerzők commitjai látszanak, nem csupán egyetlen összevont kódkülönbség.
A kódtár az alkalmazástól függetlenül is használható
Az újonnan létrehozott projektek a wordpress-develop vagy a Gutenberg teljes történetét elérhetővé teszik. A régi fájltartalmak ugyanakkor csak igény esetén töltődnek le, ezért a bejelentés szerint a helyigény nem sokkal nagyobb az 1.0 által készített, korlátozott előzményű klónénál.
A projekt mappájában a git log, a git blame és a git bisect ugyanúgy használható, mint más klónozott kódtáraknál. Ez lehetővé teszi az előzmények vizsgálatát és egy hiba bevezetési pontjának keresését anélkül, hogy a munkát másik repositoryba kellene átvinni.
A parancssoros használatot a Toolkit együttműködési szabályok szerint kezeli. Az olvasási műveletek nem zavarják az alkalmazást; ha viszont a fejlesztő kézzel merge-öt vagy rebase-t indít, a felület addig nem ír a kódtárba, amíg az be nem fejeződik vagy meg nem szakad, és megmutatja az ehhez szükséges parancsokat.
A helyi munka nem függ a Toolkit további telepítettségétől. Az alkalmazás eltávolítása után, illetve a mappa másik gépen történő megnyitásakor a repository az ott rendelkezésre álló Gittel használható tovább.
A böngészőből érkező Trac-hivatkozások közvetlenül átadják a jegyet
Az 1.1 óta támogatott wpct://ticket/N hivatkozásokkal egy Trac-jegy közvetlenül megnyitható az alkalmazásban. A Toolkit megerősítést kér a hozzárendelés előtt, mert az ágváltással jár.
Ha a hivatkozás megnyitásakor Gutenberg-projekt aktív, a jegy megnyitásához Core-projektet kell megnyitni. Windowson a linkek használata előtt legalább egyszer el kell indítani az alkalmazást.
A bejelentés konkrét példaként a WP Trac Triager Chrome-bővítményt (új ablakban nyílik meg) említi. Ez a Trac-jegyekhez olyan hivatkozást ad, amely átvezeti a feladatot a Toolkitbe, ahol a kapcsolódó pull requestek tesztelhetők.
A következő változat előkészítéséhez a teljes Gutenberg-folyamat visszajelzéseit várják
A Gutenberg-támogatás új funkció, ezért a fejlesztők különösen azokat a tapasztalatokat várják, amelyek egy issue-hozzárendeléstől egészen a pull request beküldéséig követik a munkát. A hibák a projekt GitHub-hibakövetőjében (új ablakban nyílik meg) jelenthetők, az általános észrevételekhez külön visszajelzési űrlap és alkalmazáson belüli gomb is rendelkezésre áll.
A szakmai egyeztetés helye Core-témákban a #core, a Gutenberg-folyamattal kapcsolatban a #core-editor Slack-csatorna. A bejelentés a következő verzióhoz visszajelzéseket gyűjt, konkrét megjelenési dátumot vagy rögzített funkciólistát azonban nem közöl.
