Co je tentokrát špatně? Část III:Hluboký konec

Část III:The Deep End

V tuto chvíli jsem si nebyl jistý, kam jít dál.

Proč by nyní měly mít tyto blogové příspěvky zdánlivě náhodné datum zveřejnění, které nebylo aktuální datum a nebylo to datum, kdy byly poprvé přidány do repozitáře? Co se dělo?

Takže jsem udělal to, co dělá většina programátorů v takové situaci:přidal jsem nějaké console.log() s.

Kopání hlouběji

Chtěl jsem vědět, jaké commity jsou k dispozici a jaké mají informace. Jinými slovy, chtěl jsem lepší pozorovatelnost do toho, co se dělo v této části kódové základny.

Můj první nápad byl prostě vytisknout data každého řádku vráceného z git log . Výstup toho (pro daný blogový příspěvek) vypadal nějak takto

lines returned from git log
2022-01-09T20:48:23+00:00
2022-01-06T09:18:41+00:00

...dobře, není to příliš užitečné. Proč jsou zde pouze dva závazky? Jsou to stejné informace, jaké jsme měli na webu. Možná by bylo o něco užitečnější vytisknout hash každého potvrzení? Pak jsem mohl zkontrolovat, jestli na těchto commitech není něco neobvyklého

lines returned from git log
69e038a919e448251fa2211a9fcf3fda914812fe @ 2022-01-09T20:48:23+00:00
d5cf8fbc05891ac9d8d7067b5cb1fb195dc2cf99 @ 2022-01-06T09:18:41+00:00

Nyní můžeme na GitHubu vyhledat daný odevzdání dc2cf99 .

Ale toto potvrzení nepřidává ani neaktualizuje žádné blogové příspěvky... tak proč se vrací z git log <path/to/blogpost> ?

Co když git log ged soubor, který má určitě existuje od prvního odevzdání, například index.tsx . Zkusil jsem vytisknout každý řádek protokolu pro tento soubor a na Vercelu jsem viděl následující

lines returned from git log index.tsx
69e038a919e448251fa2211a9fcf3fda914812fe @ 2022-01-09T20:48:23+00:00
88c420835d35a008de808b7cef04980a15b029bc @ 2022-01-09T12:55:49+00:00
0a882cf5062e4c0ac4505ed609ca77f14b35a76a @ 2022-01-08T20:15:44+00:00
d4a9a360c38398cdd41825aa0fe193e8176cb4fd @ 2022-01-07T22:41:52+00:00
3acb76c1f6c6d1b4cdb76939496e251220aa29ea @ 2022-01-06T20:09:17+00:00

Vrátí se zpět pouze pět commitů! Historie odevzdání vypadala stejně i pro jiné soubory s dlouhou životností. Vždy se vrátím k poslednímu závazku 6. ledna.

Spuštění stejného kódu na mém místním počítači poskytuje mnohem více potvrzení, až k prvnímu potvrzení 2. ledna.

Co dává?

Mělký konec

V tuto chvíli jsem si nebyl jistý, kolik dalšího ladění mohu udělat. Začal jsem tedy trochu zkoumat.

A našel jsem tento problém („Jak unshallow repo?“) na Vercel GitHub repo

To zní jako můj problém! A zní to, jako by to způsobil Vercel, který vytvořil mělký klon mého git repo před vytvořením. Nikdy jsem se nesetkal s mělkým klonováním ve volné přírodě dříve, ale věděl jsem o tom jako o konceptu, a tak jsem našel problém GitHubu.

Jak to tedy můžeme obejít? Jednoduše nebudeme mít v době sestavování dostupné informace, abychom mohli určit správná data „zveřejnění“ a „poslední aktualizace“ pro daný blogový příspěvek.

Ale vždy existuje způsob, jak tyto druhy omezení obejít. V tomto případě se jedná o mezipaměť.

Mezipaměť vládne všemu kolem mě

Existuje několik způsobů, jak tento problém vyřešit. Mohli bychom například použít GitHub API k získání informací o potvrzení z repozitáře hostovaného na GitHub.com. Rozhodl jsem se to neudělat, protože jsem raději ponechal řešení samostatné:všechny informace máme dostupné v době sestavování když běží lokálně , jak bychom tedy mohli tyto informace zpřístupnit při vytváření pro výrobu (na Vercelu), také? (Kde budeme mít mělký klon repo.)

Namísto volání API přes internet pro informace, které jsou dostupné lokálně, jsem si myslel, že bychom mohli tyto informace jednoduše uložit do mezipaměti a pak použít tuto mezipaměť při budování na Vercelu.

Pracovní postup, který jsem vymyslel pro psaní blogových příspěvků (a ukládání důležitých informací git do mezipaměti), vypadal asi takto

1. navrhnout wip- příspěvek (tyto jsou ignorovány pro správu verzí mým .gitignore )
2. až bude koncept připraven, git commit to na development větvete a zatlačte na Vercel
3. pro...
   • nové příspěvky na blogu (kde jediný odevzdání v git log je aktuální odevzdání), Vercel předpokládá, že příspěvek je zcela nový a pro časy „zveřejnění“ a „poslední aktualizace“ použije datum aktuálního potvrzení
   • staré blogové příspěvky (kde na tento blogový příspěvek odkazuje více než jeden odevzdání), Vercel hledá v mezipaměti časy „zveřejněno“ a „naposledy aktualizováno“, a pokud žádné nenalezne, vyvolá chybu

S tím je několik malých problémů.

Za prvé, kdy aktualizujeme mezipaměť? Všimnete si, že ve výše uvedeném pracovním postupu není žádný krok, který by zajistil, že mezipaměť je aktuální. Vzhledem k tomu, že k požadovaným informacím máme přístup pouze při lokálním stavění, musíme při lokálním stavění mezipaměť aktualizovat. Ale kdy se tyto informace dostanou do vzdáleného úložiště? Musíme to také prosadit.

Za druhé, výše uvedený pracovní postup má problém, když sloučíme development větvete do master větev při propagaci nového vydání do produkce -- samotné potvrzení sloučení znamená, že "nový" příspěvek na blogu je nyní ve dvou potvrzeních. Jak je nastíněno výše, způsobí to Vercelovi, že pokud příspěvek není v mezipaměti (nebude), vyvolá chybu.

Takže... Co teď?

Implementoval jsem několik hackerských oprav pro výše uvedené problémy.

Například mám před-push git hook, který spouští sestavení před každým git push . To znamená, že teoreticky je mezipaměť vždy aktuální. Ale samozřejmě se musím ujistit, že git add to v dalším spáchat.

Pokud jde o problém „sloučení vytvoří nový odevzdání“, vyzkoušel jsem zatím dvě řešení.

První bylo rozlišit mezi odevzdáním na development větev a odevzdá na master větev. Pouze blogové příspěvky s odevzdáním na master by měl být považován za "starý". To funguje skvěle, když běží lokálně, ale zdá se, že klon, který Vercel vytvoří, se přejmenuje tento development větev na master při vytváření náhledového nasazení. Takže to je zakázáno.

Druhé řešení (které aktuálně používám) je jednoduše ignorovat slučovací commity.

Zatím se zdá, že výše uvedené funguje. Ale připadá mi to jako příliš složité a křehké řešení a doufám, že to v budoucnu vylepším. Možná je snazší jen dotazovat se na GitHub na historii odevzdání, než procházet všemi těmi problémy s mezipamětí.

Závěr

Takže je to! Cíl byl jednoduchý:zbavit se libovolných „publikovaných“ časů v příspěvcích na blogu a vytáhnout tato data přímo z historie git projektu. Ale řešení bylo nakonec mnohem složitější a nuanční, než jsem původně plánoval.

Ale po cestě jsem se naučil nějaké nové nástroje a triky, dozvěděl jsem se trochu víc o tom, jak je moje repo sestaveno a nasazeno na Vercelu, a mám pár nápadů, jak bych mohl věci v budoucnu zjednodušit. A to je to, co to všechno má být, opravdu, zkušenost s učením.

V budoucnu možná skoncuji s tímto příliš složitým mechanismem ukládání do mezipaměti, ale chci získat data „zveřejnění“ a „poslední aktualizace“ z historie git repo. Toto počáteční řešení, i když je chaotické, zatím funguje.