Forum » Pomoč in nasveti » Omejitev dostopa za self-hosted runnerje na odprtokodnem GitHub projektu
Omejitev dostopa za self-hosted runnerje na odprtokodnem GitHub projektu
mojca ::
Malce nenavadno vprašanje.
Ali obstaja možnost, da bi na odprtokodnem projektu na GitHub-u job-e lahko samo določena grupa razvijalcev poganjala CI na self-hosted runner-jih, vsi ostali contributor-ji pa le na tistih, ki jih nudi GitHub?
Nekaj let na GitHub-u razvijamo projekt, ki bi ga želeli čez en mesec opensource-at. Trenutno se uporablja privaten repozitorij na GitHub-u, za CI pa:
* delno self-hosted runnerji (npr. Mac Mini na ARM-u, Windows, ...)
* delno GitHub-ovi large runnerji
* delno običajni GitHub-ovi runnerji (za tista opravila, ki se izvedejo dovolj hitro).
Težava je, da so običajni GitHub-ovi runnerji, ki bodo po opersource-anju celo zastonj, za precej nalog neuporabno počasni. Koda se na njih bodisi kompajla eno uro, bodisi se sploh ne (na Windowsih ne moremo več kompajlat, ker zmanjka spomina). GitHub-ovi large runnerji so boljši, a zlasti na Windowsih še vedno neuporabno počasni. Za morebitne zunanje razvijalce načeloma ni problem, če CI job teče dve uri, za zaposlene razvijalce pa je to ozko grlo, in zaposlenim bi radi dali na voljo self-hosted runner.
Težava je, da ne najdem opcije, kako bi self-hosted runner za javen repozitorij omejili samo na določeno skupino razvijalcev. Gre zlasti za vidik varnosti.
Ali obstaja možnost, da bi na odprtokodnem projektu na GitHub-u job-e lahko samo določena grupa razvijalcev poganjala CI na self-hosted runner-jih, vsi ostali contributor-ji pa le na tistih, ki jih nudi GitHub?
Nekaj let na GitHub-u razvijamo projekt, ki bi ga želeli čez en mesec opensource-at. Trenutno se uporablja privaten repozitorij na GitHub-u, za CI pa:
* delno self-hosted runnerji (npr. Mac Mini na ARM-u, Windows, ...)
* delno GitHub-ovi large runnerji
* delno običajni GitHub-ovi runnerji (za tista opravila, ki se izvedejo dovolj hitro).
Težava je, da so običajni GitHub-ovi runnerji, ki bodo po opersource-anju celo zastonj, za precej nalog neuporabno počasni. Koda se na njih bodisi kompajla eno uro, bodisi se sploh ne (na Windowsih ne moremo več kompajlat, ker zmanjka spomina). GitHub-ovi large runnerji so boljši, a zlasti na Windowsih še vedno neuporabno počasni. Za morebitne zunanje razvijalce načeloma ni problem, če CI job teče dve uri, za zaposlene razvijalce pa je to ozko grlo, in zaposlenim bi radi dali na voljo self-hosted runner.
Težava je, da ne najdem opcije, kako bi self-hosted runner za javen repozitorij omejili samo na določeno skupino razvijalcev. Gre zlasti za vidik varnosti.
strawman ::
Prva rešitev, ki mi pade na pamet je:
- Ustvariš dodaten "pipeline" projekt, na katerem lahko delajo spremembe le zaposleni. Ta vsebuje le definicijo pipelina.
- Dodaš trigger job v prvotni projekt, ki kliče ta downstream pipeline.
- V downstream pipelinu runner "tags" nastaviš kot spremenljivko, ki je odvisna od tega, kdo pipeline izvrši - če ga izvrši zaposleni gre na self-hosted runner, drugače na public.
Ni ravno elegantno, deluje pa. Verjetno bi lahko kaj sčaral tudi z ločenim runnerjem na protected branchu, ali kako drugo opcijo kjer ti zunanji ne morejo spreminjati definicije .gitlab-ci.yml datoteke.
- Ustvariš dodaten "pipeline" projekt, na katerem lahko delajo spremembe le zaposleni. Ta vsebuje le definicijo pipelina.
- Dodaš trigger job v prvotni projekt, ki kliče ta downstream pipeline.
- V downstream pipelinu runner "tags" nastaviš kot spremenljivko, ki je odvisna od tega, kdo pipeline izvrši - če ga izvrši zaposleni gre na self-hosted runner, drugače na public.
Ni ravno elegantno, deluje pa. Verjetno bi lahko kaj sčaral tudi z ločenim runnerjem na protected branchu, ali kako drugo opcijo kjer ti zunanji ne morejo spreminjati definicije .gitlab-ci.yml datoteke.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | VSCode povezava na privatni gitOddelek: Programiranje | 1488 (886) | CaqKa |
» | Kateriega git repository providerja uporabljate?Oddelek: Programiranje | 1985 (1227) | Spura |
» | Kaj uporabljate oz. priporocate za code review?Oddelek: Programiranje | 2155 (1096) | showsover |
» | Apache gre na GitHubOddelek: Novice / Ostale najave | 6458 (3885) | Ales |
» | Evropska komisija dovolila Microsoftov prevzem GithubaOddelek: Novice / Nakupi / združitve / propadi | 10246 (7812) | Ales |