Úgy érzed, hogy a projekted dependeny-jeinek karbantartása időigényes? Több mint tíz backend szolgáltatás és néhány front-end alkalmazás könnyen elérhet valamit, amit el akarsz kerülni. Gondolom, már ismerős az automatizált eszközök, mint például a Dependabot és a Renovate, hiszen ezek kulcsfontosságúak egy egészséges projekt szempontjából.

A mi kontextusunk

A CommIT Smart-nál ügyfeleink számára piacképes alkalmazás szolgáltatásokat nyújtunk. Partnereink infrastruktúrájának, backend szolgáltatásainak és frontend alkalmazásainak naprakésszé tételéhez ezt az automatizált megoldást biztosítjuk.

Milyen eszközöket és programozási nyelveket használunk?

• GitLab, GitLab CI

• GoLang, Java, React, Angular, React-native, Terraform, Docker, Kubernetes, Helm

• Renovate

Hogyan konfiguráltuk a Renovate-et?

Minden, amit csinálunk, a GitLab Folyamatos Integráció automatizálásával történik. Rendkívül kényelmes volt a pipeline beállítása a Renovate használatával.

Először létre kell hoznia a saját tárolóját. Adja hozzá az alábbi tartalmat a gitlab-ci.yml-hez:

include:

- project: 'renovate-bot/renovate-runner'

file: '/templates/renovate.gitlab-ci.yml'

Egy előre meghatározott renovate.gitlab-ci.yml fájlt használ a renovate-bot/renovate-runner GitLab projektből. A renovate.gitlab-ci.yml fájl tartalmazza azokat a szakaszokat, amelyek új verziókat keresnek a projektjeiben.

A projektjeinek bevonásához definiálnia kell egy CI/CD változót, amit RENOVATE_EXTRA_FLAGS-nek hívnak. Navigáljon a Gitlab tárhelyre, nyissa meg a Beállítások > CI/CD > Változók menüpontot. Adjon hozzá egy új változót.

Itt így adtuk hozzá a jelzőt: RENOVATE_EXTRA_FLAGS=--autodiscover=true --autodiscover-filter=/commitsmart/.*/

Github.com token a kiadási jegyzetekhez (opcionális) Ahogy a renovate dokumentációja írja:

Ha nem github.com platformon fut, fontos, hogy egy környezeti változót – GITHUB_COM_TOKEN – is konfiguráljon, amely tartalmaz egy személyes hozzáférési tokent a github.com-hoz. Ez a fiók valójában bármely GitHub fiók lehet, és csak olvasási hozzáférést igényel. A kiadási jegyzetek lekérésére használják a tárolókhoz, hogy növeljék az óránkénti API limitet. Ha szeretné, ugyanazt a hoszt szabályaként is konfigurálhatja.

Létrehoztuk a személyes hozzáférési tokent, és hozzáadtunk egy új GITHUB_COM_TOKEN változót az általunk létrehozott renovate runner tárolóba.

GitLab CI Ütemező

Az egyetlen dolog, amit még konfigurálnunk kell, az a CI Ütemező. Navigáljon a Gitlab tárhelyre, nyissa meg a CI/CD > Ütemezések menüpontot. Hozzon létre egy új ütemezőt az Ön által választott paraméterekkel. Az ütemezőt ilyen mintával hoztuk létre: 0 * * * * . Minden órában fut, ami elég gyakori ahhoz, hogy a projektjeink frissek maradjanak.

Végül a runner sikeresen konfigurálva lett. Ahhoz, hogy a renovate tudja, mi lenne az egyes projektjei célja, szüksége lesz, hogy létrehozzák a projekt-szintű konfigurációt.

Renovate konfiguráció hozzáadása az alkalmazás tárolójához

Egy GoLang-alapú tárolót választottam. A Go projektek go.mod & go.sum fájlokat tartalmaznak. A go.mod tartalmazza a függőségeket és azok verzióit, a go.sum pedig a konkrét modul verziók tartalmának várt kriptográfiai ellenőrző összegeit. Ha egy verziót frissít, futtatnia kell a go mod tidy parancsot is. Ez frissíteni fogja a go.sum fájlt. A Renovate nem fogja ezt automatikusan futtatni, de megoldást kínál erre.

Hozzon létre egy új fájlt a projektje gyökerében renovate.json néven. Az alábbi konfigurációval rendelkezünk az egyik legegyszerűbb Go projekthez:

{

"extends": ["config:base"],

"labels": ["renovate", "dependencies"],

"postUpdateOptions": ["gomodTidy", "gomodUpdateImportPaths"],

"assigneesFromCodeOwners": true,

"packageRules": [

{

"matchUpdateTypes": ["minor", "patch", "pin", "digest"],

"automerge": true

}

]

}

Mindenekelőtt a config:base-et fogja használni az alapértelmezett konfiguráció kiterjesztéséhez. A labels azt mondja a renovate-nek, hogy adjon hozzá renovate & dependencies címkéket az általa létrehozott MRs-hez. A postUpdateOptions végtelen funkciót biztosít mindenféle projekthez, itt megadhatjuk a gomodTidy & gomodUpdateImportPaths hozzáadását. Ezek frissítik a függőségeket, ahogy szeretnénk. Az MRs létrehozása után a Renovate azokat a kód tulajdonosoknak rendeli. Ehhez elolvassa a CODEOWNERS fájlt (ez azt jelenti, hogy először hozzá kell adnia egy codeowners fájlt).

A trükkös rész a packageRules. Az eredeti cél az volt, hogy csökkentsük az új verziók keresésére, MRs frissítésére, áttekintésére és egyesítésére fordított időt. Ez a kódrészlet ebben is segít. Ennek köszönhetően, a Renovate automatikusan egyesíti azokat az MRs-eket, amelyek kisebb frissítésekről, hibajavításokról, PIN-kódokról vagy szövegrészletekről szólnak. A lépések a következők:

• Renovate első futás megkezdése

• Renovate új verziókat ellenőriz & MRs-eket hoz létre

• Rendelje hozzá egy kód tulajdonoshoz

• Renovate első futása befejeződik

• Közben az MR pipeline sikeres

• Renovate második futás megkezdése

• Renovate ellenőrzi az előzőleg megnyitott MRs-eket

• Ha auto-merge engedélyezve van, egyesíti az MR-t

• Renovate új verziókat ellenőriz & MRs-eket hoz létre

Milyen az MR megjelenése?

Van egy kiadási megjegyzés az aktualizált csomagról. Miben különbözik az új verzió a régitől? A fájl ott van. Az automatikus egyesítés engedélyezve van? Ezt is ott találhatja. Ugye menő?

Összefoglalás

• Új tároló létrehozása

• Gitlab-ci.yml hozzáadása a renovate-bot sablonjának beillesztésével

• CI/CD változók hozzáadása

• CI/CD ütemező hozzáadása

• Renovate konfiguráció hozzáadása alkalmazás projektekhez

Szerző: Csaba Ujvári