Gitlab Free wordt beperkt, over naar Azure Repos

Ingediend door Dirk Hornstra op 26-sep-2022 22:04

Gitlab is per 19 oktober voor de free-accounts minder aantrekkelijk: maximaal 5 accounts en maximaal 5 GB. En misschien nog wel meer beperkingen. Waar ik werk programmeren we in C# en maken (dus) gebruik van Visual Studio, daarom kunnen we ook Azure Repos gebruiken als GIT-systeem, opslag van broncode en versiebeheer.

Je kunt in Azure Repos via de web-interface in projecten repositories importeren, maar als je er meer dan 200 hebt, dat wil je automatiseren. Dat kan via de API: url.

Als je een import uitgevoerd hebt, dan zie je netjes alle commits en branches. Maar je ziet geen Pull Requests. En die willen we natuurlijk ook overzetten (in Gitlab heten dit merge-requests). Voor het gemak noem ik ze PRs.

Een PR is op zich niet meer dan een registratie dat je branche A wilt samenvoegen met branche B. Aangemaakt door persoon X. Die mogelijk nog een aantal “reviewers” gekoppeld heeft die moeten beoordelen of de wijzigingen die dan overgezet worden correct zijn.

In Azure Repos heb je “refs”. Hierin staan de branches en ook de PRs. Daar kun je in code doorheen bladeren [link] en vervolgens aanmaken als PR.

We hebben een systeem-user met een token die deze acties uitvoert. Maar... de PRs worden dan ook gekoppeld aan die systeem-user als aanmaker. En dat klopt dus niet. Wel voeg ik via een tag de echte aanmaker van het PR toe. Daarom hebben we gevraagd aan de devs om een eigen token te maken en deze te importeren in onze applicatie. We kunnen dan per PR een create-actie uitvoeren met die user + token van de user.

Hiermee hebben we een import-procedure die ervoor zorgt dat we bijna geruisloos over kunnen stappen van Gitlab naar Azure Repos.

Mocht je zelf ook deze actie moeten uitvoeren, nog één aanvullend punt. Zelf zit ik als admin in het systeem en dan mag je dus alles. Maar over het algemeen is een dev een “contributor”, iemand die bijna alles mag binnen een repository en repository’s aan kan maken. Een collega gaf aan dat hij zijn eigen branche niet kon/mocht verwijderen. En omdat we vroeger als standaard branche “master” hadden, hebben we dat als de project-standaard ingesteld. Maar we hebben ook een aantal branches waarbij de standaard branche “main” is. Omdat dit er geen master is, wordt de eerste als standaard gekozen, meestal een feature-branche. Als je dan een nieuwe branche aan wilt maken, wordt standaard de feature-branche als bron geselecteerd en moet je dus elke keer via wijzig - selecteer “main” de juiste bron-branche selecteren. Extra, onnodig en ook foutgevoelig (ziet iemand het over het hoofd, dan start je met de foutieve bron voor je nieuwe branche en loop je later bij mergen tegen problemen aan).

Bij het overzicht van branches kun je uiterst rechts op de 3 puntjes klikken en die branche voor de repository als standaard instellen. Maar dat kon mijn collega ook niet.

Ga in je Azure-omgeving naar het project. Ga naar “project settings”. Klik op Repositories. Klik op het tabblad “Security”. Klik op de groep “Project Contributors”. En zet dan alles op “Allow”, behalve het verwijderen van repo’s. Daarmee hebben de devs voldoende rechten om zonder problemen hun werk te kunnen doen.