Continuous Integration na GitHub Pages w Buddy.works • Type of Web

Poniższy artykuł powstał we współpracy z Buddy.works.

Continuous Integration i GitHub Pages

Pod wpisem dotyczącym wrzucania React.js na GitHub Pages w sekcji komentarzy pojawiło się spore zainteresowanie tym tematem. Wiele osób pytało mnie też na Discordzie o automatyzację wrzucania zmian na GitHub Pages. Jak automatycznie aktualizować stronę na GitHub Pages, gdy wprowadzamy zmiany w kodzie? Musimy skonfigurować usługę Continuous Delivery i podłączyć ją z GitHubem! Użyjemy Buddy.works.

Buddy

Jak pisałem w poprzednim artykule, Buddy to narzędzie do CI/CD, które wyróżnia się tym, że jest niezwykle łatwe w użyciu, a do tego mega szybkie! Praktycznie cały, nawet najbardziej skomplikowany proces można stworzyć bez ręcznego edytowania plików konfiguracyjnych.

CI, GitHub Pages, Buddy

Potrzebne nam będą:

Konto na GitHubie i repozytorium z kodem. Zmiany w kodzie będą automatycznie wrzucane także na GitHub Pages. Ja użyję przykładowego repo github.com/mmiszy/typeofweb-buddy
Konto na Buddy.works (można zarejestrować się swoim kontem na GitHubie).

Na potrzeby 1. użyję aplikacji w React.js. Przed wrzuceniem jej na GitHub Pages będę musiał ją skompilować i zminifikować.

Projekt w Buddy

Po zalogowaniu się do Buddy, wita mnie ekran dający możliwość stworzenia nowego projektu i tak też czynię. Buddy udostępnia integrację z wieloma dostawcami repozytoriów gita: GitHub, Bitbucket, GitLab, własny hosting Buddy oraz prywatny serwera gita. Wybieram opcję GitHub i wyszukuję swoje repozytorium.

Stworzenie aplikacji w React.js i przygotowanie jej do wrzucenia na GitHub pages opisywałem w kursie React.js.

Buddy od razu wykrył, że w repozytorium znajduje się aplikacja Reactowa i zasugerował konfigurację. Klikam "Add new Pipeline", jako nazwę podaję "Deploy to GitHub Pages", wybieram "On Push" i resztę opcji zostawiam domyślnie (Single branch, master). Tworzy się tak zwany "pipeline", czyli to, co zostanie wykonane automatycznie po wprowadzeniu każdej zmiany w repozytorium.

Ja chciałbym wykonać 3 kroki:

yarn lub npm install
yarn build lub npm run build
gh-pages -d build

Dla ułatwienia dodaję je jako skrypty npm (zobacz wcześniej linkowany artykuł):

{
  "scripts": {
      "predeploy": "npm run build",
      "deploy": "gh-pages -d build",
      …
  }
}

Następnie w buddym tworzę akcję i używam powyższych skryptów:

yarn
yarn deploy --user='Michal Miszczyszyn <michal@mmiszy.pl>' --repo=https://$GITHUB_TOKEN@github.com/$BUDDY_REPO_SLUG.git

Prawa do zapisu do GitHub Pages na CI

Ostatnia linijka jest szczególnie warta uwagi. Ustawiam tutaj nazwę i email potrzebne do commita w gicie, a następnie podaję adres repozytorium. Buddy nie ma prawa pushować niczego do mojego repo (nikt oprócz mnie nie ma), a ja zdecydowanie nie chcę podawać mu swojego hasła. Aby więc umożliwić deploy, musimy podać adres repozytorium poprzedzony $GITHUB_TOKEN@, a także zdefiniować zmienną środowiskową zawierającą token.

Skąd wziąć token? Można go wygenerować na https://github.com/settings/tokens. Ważne, aby nadać mu uprawnienia repo, które są niezbędne, aby móc zaktualizować stronę na GitHub Pages. Po zapisaniu, token widoczny będzie tylko jeden jedyny raz. Skopiuj go gdzieś na chwilę i nikomu nie udostępniaj!

Zmienne środowiskowe w Buddy

Wracamy do Buddy, nadal edytujemy pipeline. W zakładce "variables" klikamy "Add new variable" i jako nazwę (Key) wpisujemy GITHUB_TOKEN, a jako wartość (Value) wygenerowany przed chwilą token. Możemy też wybrać Scope (czyli, czy ta zmienna ma być widoczna wszędzie, tylko w tym projekcie, czy tylko w tym pipelinie). Co istotne, w polu Encryption wybieramy "enabled", czyli włączamy szyfrowanie.

Szyfrowanie należy włączyć dla każdej zmiennej, która zawiera tajne informacje. Token jest tajny.

Buddy ma także wiele predefiniowanych zmiennych. Jeśli wrócimy na chwilę do edycji akcji i wpiszemy tam $, to powinniśmy zobaczyć listę wszystkich dostępnych zmiennych.

Zmienne środowiskowe dostępne w akcjach. Lista zawiera także zmienną dodaną przez nas.

Testowanie CI

Fajnie by było sprawdzić, czy nasze Continuous Integration działa bez konieczności wprowadzania bezsensownych zmian w gicie tylko do testów. Buddy umożliwia to w bardzo prosty sposób: Klikamy "Run pipeline" i "Run now". Po krótkiej chwili powinniśmy zobaczyć na ekranie zielony komunikat "Build finished successfully!". Co istotne, każde kolejne uruchomienie tego samego pipeline'a będzie szybsze, niż pierwsze!

Efekty

Jeśli prawidłowo skonfigurowaliśmy repozytorium, to po wejściu na adres naszego GitHub Page powinniśmy zobaczyć już naszą stronę. Moją stroną możecie podejrzeć pod adresem mmiszy.github.io/typeofweb-buddy i wygląda ona tak, jak na screenshocie.

Sprawdźmy, czy strona się zaktualizuje automatycznie po wykonaniu git push. Od razu po wysłaniu zmian do repo w Buddy uruchamia się skonfigurowany przez nas pipeline i po 16 sekundach zmiany są już na GitHub Pages. Przy takiej prędkości, to naprawdę Continuous Delivery!

Podsumowanie

To była intensywna lekcja. Pokazałem, jak skonfigurować prosty pipeline w Buddy.works i podpiąć go tak, aby uruchamiał się przy każdej zmianie w repozytorium na GitHubie. Co więcej, ustawiliśmy wszystko w taki sposób, aby Buddy miał prawa do commitowania do naszego repozytorium przy użyciu bezpiecznego tokena i dzięki temu mógł aktualizować stronę na GitHub Pages!

Myślę, że opisane przeze mnie możliwości, czyli Continuous Delivery na GitHub Pages dzięki Buddy przydadzą się każdemu, choćby do budowania swojego portfolio, bloga, czy aplikacji klientów. Konfiguracja całego procesu zajmuje tylko kilka chwil, a zyskujemy oszczędność czasu i wygodę.