Projekty

Jeden produkt, jeden projekt

Projekt je místo, kam dopadá práce na jednom produktu: jeho úkoly, nástěnky, nahraná sezení, hlášení a vydání. vitrinka setup při prvním spuštění zařadí repozitář pod projekt; vitrinka project link [project] zařadí další checkout pod už existující projekt — další repozitář projektu s více repozitáři — a vitrinka project unlink checkout zase odpojí a odebere jeho řádek z repozitářů projektu.

Nastavení → Projekty vypisuje všechny projekty workspace. Po otevření projektu uvidíte jeho název, jeden řádek o stavu a pět záložek: Overview · Routing · Repositories · Fields · Review. Overview, Routing a Repositories jsou koncepty s vlastním tlačítkem Save; Fields a Review ukládají každý řádek hned při změně.

Overview

Název, který ukazuje postranní panel — slug je adresa a nikdy se nemění — a stav: active, tedy produkt, nebo system, tedy infrastruktura skrytá z postranního panelu. Projekt sloučený do jiného je tu jen ke čtení; sloučený i přesunutý jinam odkazuje na svůj nový domov.

Záložku otevírá ikona: nosí ji dlaždice projektu na launchpadu, jeho řádek v liště Work, jeho drobečková navigace a záložka prohlížeče na jeho vlastních stránkách. Fetch from site ji načte z produkční domény projektu nebo z adresy, kterou vložíte — jen z veřejných webů a nikdy na instalaci odpojené od internetu; Upload… přijme soubor PNG, JPEG, WebP, GIF, ICO nebo SVG; vitrinka setup pošle vlastní ikonu repozitáře, aniž by sáhl na jakýkoli web. Workspace bez vlastního loga převezme ikonu prvního projektu a volba admina v Nastavení → Workspace vždy vyhrává. Skripty volají PUT /api/v1/projects/{project}/icon s obrázkem jako tělem požadavku.

Routing

Která nahraná sezení patří do tohoto projektu. Domains porovnají hostitele záložky prohlížeče se vzorem a označí sezení prostředím pravidla; App ids porovnají bundle id aplikace v Expu a app id, které už vlastní jiný projekt, server odmítne. Doména s produkčním prostředím (production, prod, prd nebo live) ukáže navíc přepínač in-app recorder pro webový rekordér. Skripty zapisují stejná pravidla přes PUT /api/v1/projects/{project}/settings — viz rozšíření prohlížeče.

Repositories

Repozitáře na GitHubu, ve kterých žije kód projektu. První je výchozí pro commit pilulky, prohlížeč kódu a sběr pro vydání; nový release track převezme všechny. Pověřením je GitHub App workspace a tenhle seznam je vazba: řádky se doplňují z toho, na co navázané účty dosáhnou, a repozitář na github.com, který žádný z nich nepřečte, dostane varování, nikdy blokaci, takže vlastní hostovaný git zůstává v pořádku. Klíč úkolu ve sloučeném pull requestu z repozitáře mimo tento seznam úkol propojí, ale nikdy nedokončí (pravidla).

Fields

Typovaná vlastní pole pro úkoly projektu — text, dlouhý text, výběr, vícenásobný výběr, checklist, číslo, datum, URL nebo vazba na jiný úkol — každé pro jeden typ úkolu nebo pro všechny, seskupená podle typů, na které se vztahují. Pod nimi Type faces nastaví glyf, který každý typ úkolu v projektu nosí. Pole definuje správce, tady nebo z terminálu; hodnoty žijí na úkolech a nastavují se ve vlastnostech úkolu nebo přes vitrinka task field set. Pole typu výběr se stanou aspekty filtru. Klíč a druh pole se nikdy nemění a odebrání pole smaže všechny hodnoty, které pod ním byly uložené.

vitrinka project fields add customer "Zákazník" --kind select --options acme,globex --applies-to bug
vitrinka task field set 418 customer acme

Review

Vrstva review rubriky pro projekt: každé pravidlo, které projekt dědí z vestavěných a z workspace, s přepínačem zapnutí, editorem a návratem k vrstvě pod ním. Samotnou rubriku popisuje sada nástrojů pro revize.

Sloučení dvou projektů

merge into… v záhlaví nastavení projektu ho sloučí do jiného projektu téhož workspace. Přesune se všechno — úkoly s historií, nástěnky, sety, sezení, hlášení, vydání i paměť projektu — a starý název se stane aliasem nového domova, takže každý starý odkaz dál funguje. Dialog nejdřív ukáže náhled (zkoušku nanečisto, jejíž report je transakce samotného sloučení, vrácená zpět), pak sloučí po potvrzení. Vlastní pole s kolidujícím druhem dorazí přejmenované na <key>-from-<old name> a hodnoty si ponechá; průběžné vydání zdroje se přidá k průběžnému vydání cíle.

Sloučení, náhled včetně, je rozhodnutí vlastníka workspace, které dělá jako člověk; tokeny agentů server odmítne a pošle je na CLI. Chcete-li přesunout jen některé úkoly, změňte jim projekt přes dveře úkolů — podstrom se přesune celý.

vitrinka project merge old-app --into app           # report zkoušky nanečisto
vitrinka project merge old-app --into app --apply
vitrinka project merge-plan --into app              # zbloudilé projekty, které by sloučení pohltilo

Přesun projektu do jiného workspace

vitrinka project transfer [project] --to <workspace> zkopíruje všechno, co projekt vlastní, do jiného workspace, který vlastníte — nástěnky s kartami a anotacemi, sety, sezení, hlášení, vydání a celý engine úkolů, včetně všech blobů, na které odkazují. Potřebuje vlastníka obou workspace, nikdy token agenta. Nejdřív zkouška nanečisto; opakovaný běh přeskočí, co už dorazilo. Slug nástěnky nebo klíč setu, který cíl už má, server odmítne, pokud --merge projekt nesloučí se stejnojmenným projektem na místě, a zdroj zůstane nedotčený, dokud ho --archive-source po potvrzení kopie nevyřadí. Agenti používají transfer_project.

Značky nasazení

vitrinka project deploy-mark <env> <sha> zaznamená, že commit dorazil do prostředí — fakt, na který čeká todo s podmínkou deployed <env> (todo, která dozrají sama). Spouštějte ho z nasazovací pipeline s pověřením admina nebo pipeline; pověření člena server odmítne. Agenti používají mark_deploy.

Značka prod nebo production zároveň v Historii označí práci jako vydanou. S připojenou GitHub App vydá PR nebo commit úkolu jen tehdy, když ho označený commit obsahuje, takže hotfix nasazený ze staršího tagu si nikdy nepřivlastní práci sloučenou do hlavní větve až po jeho odbočení, a jeho vlastní commity se vydají s ním. Odpověď značky hlásí lineage: ancestry s repozitářem a počtem čekajících odkazů, které obsahuje nebo vylučuje, nebo time s důvodem (bez GitHubu, commit v žádném navázaném repozitáři, GitHub příliš pomalý); pak se s nasazením vydá práce sloučená před ním. Také zamergovaný PR zaznamenaný dřív, než vitrinka ukládala merge commity, se posuzuje podle předků: značka přečte jeho merge commit z jednoho výpisu PR sloučených od chvíle, kdy na větev dorazil nasazený commit (u hotfixu místo odbočení), a lineage.filled je počítá. Když výpis selže, nestihne se nebo skončí na limitu stránek, odpověď zůstane ancestry, ale je neúplná: lineage.unfilled počítá PR, které nedokázal zařadit. Ty se vydají jako u time, s nasazením, pokud byly sloučené před ním, a lineage.reason říká proč.