Implementarea site-ului web

Site-ul F-Droid este construit folosind Jekyll și gitlab-ci. Întregul site web funcționează acum folosind un flux de lucru standard git “fork” care este bine susținut de GitLab și bine cunoscut din servicii precum GitHub. Pentru toate paginile și informațiile despre aplicațiile și pachetele distribuite de f-droid.org, paginile respective sunt generate cu ajutorul plugin-ului nostru jekyll-fdroid, care preia conținutul din fișierul de index f-droid.org.

Etapizarea pe bifurcații de dezvoltare

Toate bifurcațiile de dezvoltare ale fdroid-website au în mod automat un server de etapizare configurat și întreținut de configurația gitlab-ci. Aceasta implementează automat conținutul versiunii master a bifurcației în GitLab Pages. De exemplu, bifurcația git a lui nicoalt se află la https://gitlab.com/nicoalt/fdroid-website, iar versiunea master din aceasta este implementată automat la https://nicoalt.gitlab.io/fdroid-website.

Montarea site-ului oficial

La fel ca în cazul bifurcațiilor, branșa master a repo-ului git principal pentru site-ul web, https://gitlab.com/fdroid/fdroid-website, este distribuită automat la https://fdroid.gitlab.io/fdroid-website. Acesta este locul unde se poate revizui starea actuală a site-ului web înainte de a marca o versiune.

Implementarea pe https://f-droid.org

Atunci când o actualizare a site-ului este testată și gata de lansare, un manager de lansare creează o etichetă de lansare semnată PGP în repo-ul git principal. Serverul de desfășurare monitorizează repo-ul git principal pentru tag-uri noi. Când vede o nouă etichetă, verifică mai întâi semnătura PGP pe eticheta git folosind un breloc GnuPG configurat manual care conține numai cheile publice ale cheilor PGP cărora li se permite să eticheteze versiunile de lansare ale site-ului web.

După ce eticheta git este verificată, ținta f-droid.org din .gitlab-ci.yml este rulată pentru a genera fișierele reale pentru site. Aceste fișiere sunt apoi copiate la locul lor pe serverele f-droid.org.

Etichetele “deploy” utilizează o schemă de denumire “semantic versioning”:

  • <major>.<minor>
  • <minor> este crescut la fiecare desfășurare
  • <major> se mărește doar atunci când există modificări majore