Automatycznie generowanie numeru wersji w PKGBUILD z użyciem Git.

Automatyczne generowanie numeru wersji jest niezwykle wygodne. Kompilując ze źródeł udostępnianych na „gicie” można w znaczący sposób ułatwić sobie pracę. Może każdorazowe uzupełnianie numeru wersji nie jest czynnością skomplikowaną, jednakże skoro można sobie pracę jakoś zautomatyzować, to warto poznać kilka tego typu sztuczek. Przedstawię trzy spośród możliwości, jakie dają nam połączone siły Arch Linux oraz Git.

PKGBULID daje nam sporo możliwości – między innymi w bardzo łatwy sposób można dostosować go tak, by zamiast „tradycyjnych źródeł” wykorzystywać git do skompilowania interesującego nas programu. Funkcją odpowiedzialną za generowanie numeru wersji jest oczywiście pkgver().

I. „Lekko, łatwo i przyjemnie” czyli tak dla tag.

Pierwsza metoda jest zdecydowanie najłatwiejsza do wykorzystania i nie wymaga żadnych poważniejszych kombinacji. Jeśli autor projektu regularnie aktualizuje tagi, wystarczy, że użyjemy (przykładowo) polecenia:

git describe --long

Czasem konieczne będzie rozszerzenie tego polecenia o kolejny parametr (najczęściej o takiej konieczności poinformuje nas sam git wyświetlając odpowiedni komunikat o błędzie):

git describe --long --tags

Na przykładzie źródeł kernela wygenerowaliśmy w ten sposób numer wersji:

v4.14-rc7-0-g0b07194bb55e

Jednakże taki numer jest niedopuszczalny – numer wersji NIE MOŻE zawierać żadnych myślników. Możemy rozwiązać to w bardzo prosty sposób. Jedyne co musimy zrobić, to skorzystać z pomocy seda by zamienić myślniki na kropki:

git describe --long --tags | sed 's/^v//;s/-/./g'

Przy okazji pozbędziemy się także całkowicie zbędnego „v” sprzed numeru wersji:

4.14.rc7.0.g0b07194bb55e

Zatem całość wpisu w tym przypadku powinna wyglądać następująco:

pkgver() {
cd "${_srcname}"

git describe --long --tags | sed 's/^v//;s/-/./g'
}

II. Miłe złego początki czyli od reguły wyjątki!

Niestety, metoda opisana w punkcie I przedstawia sytuacje wzorowe czyli takie, w których tagi uzupełniane są regularnie. Życie, jak wiadomo idealne najczęściej nie jest i możemy spotkać się z niewielkimi trudnościami. Najczęściej są to sytuacje typu:

– tagów brakuje w ogóle

– tagi aktualizowane są nieregularnie

– w „magiczny” sposób git describe generuje całkowicie błędny numer wersji

Bardzo często spotykałem się z tym przy kompilowaniu kf5 – pewne elementy generowały prawidłowy numer wersji natomiast inne niestety nie. Bardzo podobny przypadek miałem także przy kompilowaniu psi-git.

Na Githubie najnowszy tag został opisany jako 1.3 tymczasem polecenie git describe generowało numer wersji:

0.15.1010.g8693e2e0

Na szczęście istnieją inne sposoby radzenia sobie w takiej sytuacji. Zdarza się, iż numer wersji można odczytać z jakiegoś pliku zawartego w projekcie. Wtedy takie polecenie może przybrać mniej więcej taką formę:

_ver="$(cat version | grep -o "[[:digit:]]*" | paste -sd'.')"
echo "${_ver}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"

Uzyskamy wówczas następujący rezultat:

1.3.r3026.g8693e2e0

Choć wygląda to bardzo skomplikowanie, to sprawa przedstawia się prosto:

– 1.3 – to oczywiście numer wersji

– r3026 – ilość wszystkich rewizji w projekcie (z polskiego na nasze: liczba wszystkich commitów)

– g8693e2e0 – to po prostu „numer” ostatniej rewizji.

Jednakże może się zdarzyć, że choć tagi wydają się być uzupełniane są na bieżąco to i tak będziemy zmuszeni użyć tej metody. Dlaczego? W niektórych projektach taguje się tylko stabilne wersje, natomiast w gałąź master zawiera źródła umożliwiające zbudowanie projektu w wersji niestabilnej (beta, rc). Takim przykładem może być Krusader. Najnowszy tag jest równy najnowszej stabilnej wersji (2.6.0) natomiast korzystając z gałęzi master zbudujemy program w wersji 2.6.1.beta. W przypadku aplikacji rozwijanych przez KDE bardzo często numer wersji zawarty jest w pliku CMakeLists.txt – to rozwiązanie bardzo ułatwia nam uporaniu się z niegodnościami „nieaktualnych” tagów:

_ver="$(cat CMakeLists.txt | grep -m1 'set(VERSION' | cut -d '"' -f2 | tr - .)"
echo "${_ver}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"

W ten sposób otrzymamy następujący numer wersji:

2.6.1.beta.r5753.g5abc4b92

Jak widzimy, jest on stworzony analogicznie do tego, co otrzymaliśmy w przypadku psi.

III. Pozostałe przypadki.

Czasem może okazać się, że nie będziemy mogli skorzystać z wcześniejszych punktów – autor nie stosuje tagów, nie możemy odczytać numeru wersji z jakiegokolwiek pliku. Przykładem mogą być różne zestawy motywów/ikon. W typ wypadku mamy różne czy też wręcz dowolne kombinacje. Ja z reguły stosuje jedną:

echo "$(git show --format='%cI' -q master | sed 's/T.*//g;s/-//g').r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"

Wygenerowany w ten sposób numer wersji wygląda następująco –

20170920.r78.gc2fb00f

– 20170920 – data ostatniej rewizji

– r78 – ilość wszystkich rewizji w projekcie (z polskiego na nasze: liczba wszystkich commitów) – analogicznie, jak w przypadku psi.

– gc2fb00f – to po prostu „numer” ostatniej rewizji, podobnie jak w przypadku psi.

Jak widzimy, czasem autogenerowanie numeru wersji jest bardzo proste, czasem wymaga nieco większych kombinacji. Jednakże gdy poświęcimy tylko chwilkę na wybór optymalnej metody, to w przyszłości będziemy ograniczeni jedynie do wykonania polecenia:

makepkg -sric

Pilnowanie numeru wersji, by samodzielnie nadać numer wersji przestanie być uciążliwą koniecznością.

Dodaj komentarz