Gitlab CI – Paczki Nuget

Zbliża się oficjalnie okres przygotowania do świąt. Czas wyciągnąć za duże, czerwone swetry, kupić skrzynkę mandarynek i odbierać od kurierów paczki dla rodziny. Nie znaczy jednak, że można przestać się rozwijać - nauka zawsze się przyda, konkurencja nie śpi. Nie chcąc być całkowicie Grinchem to dziś prezentuje artykuł o trochę innych paczkach ;)

Czym byłoby pisanie aplikacji bez paczek? NPM, Gradle, Composer, Cargo - każdy szanujący się ekosystem posiada oprogramowanie do zarządzania paczkami, wersjami itp. W niektórym językach mamy ich kilka. Ekosystem .NET-a nie odbiega od ogólnym standardów i także posiada swój package manager - Nuget. Istnieje publiczne repozytorium pod adresem Nuget.org , ale co w przypadku gdy potrzebujemy posiadać nasze prywatne repozytorium paczek nuget-a? Sprawa jest prosta , wystarczy wykorzystać Gitlab-a do przechowywania kodu źródłowego, co pokaże w poniższym artykule.

Konfiguracja Gitlab CI

Pierwszym krokiem będzie konfiguracja samego pipeline-a Gitlab CI. Oczywiście zakładając, że masz już utworzony projekt. W pliku .gitlab-ci.yml musimy zdefiniować proces budowania i uploadowania paczki do naszego repozytorium. W wersji produkcyjnej nie można zapomnieć o odpaleniu testów 😀 Aby to zrobić musimy zdefiniować job-a, a kod możemy niemal jeden do jednego przekopiować z dokumentacji Gitlab-a. Osobiście wolę zbudować paczkę nie do defaultowego katalogu, a położonego bliżej aplikacji, zazwyczaj nazywam go out. Przykładowy plik wykorzystujący zmienne środowiskowe z Gitlab-a i dotnet CLI będzie wyglądał następująco:

image: mcr.microsoft.com/dotnet/core/sdk:3.1

stages:
  - deploy

deploy:
  stage: deploy
  script:
    - dotnet pack -c Release -o ./out
    - dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" --name gitlab --username gitlab-ci-token --password $CI_JOB_TOKEN --store-password-in-clear-text
    - dotnet nuget push "out/*.nupkg" --source gitlab
  only:
    - master

Konfiguracja Projektu

Pierwsza część za nami, możemy dodać źródło paczek w naszym IDE. I tu nie kłamiąc nie ma znaczenia, czy to będzie Rider, czy Visual Studio. Jeżeli używamy systemu CI do tej aplikacji, prawdopodobnym jest, że w momencie dodania paczki z prywatnego repozytorium padnie proces budowania aplikacji. Po prostu system, który buduje aplikację, musi wiedzieć, w jaki sposób dobić się do prywatnego repozytorium.

W głównym katalogu aplikacji tworzymy plik Nuget.config. Chcąc przejść procesy uwierzytelnienia i autoryzacji podajemy nasze credentiale. Dla osób posiadających wiedzę z zakresu security może to brzmieć ryzykownie. Ale jak to przechowywać tekstem hasło lub token do gitlaba w kodzie źródłowym?". To faktycznie nie jest najlepsza praktyka. Gdyby kod źródłowy zostałby ujawniony, ktoś mógłby otrzymać dostęp do wszystkich repozytoriów. Dlatego ja preferuje idee kont "serwisowych". Utworzyłem takowe z minimalnymi uprawnieniami i mogłem kontynuować pisanie tego pliku.

    <configuration>
          <packageSources>
             <clear />
             <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
             <add key="shared" value="https://gitlab.com/api/v4/projects/{projectId}/packages/nuget/index.json" />
        </packageSources>

        <packageSourceCredentials>
            <shared>
               <add key="Username" value="{username}" />
               <add key="ClearTextPassword" value="{token or password}" />
            </shared>
        </packageSourceCredentials>
</configuration>

Inny sposób na dodanie uprawnień

Jak wspomnieliśmy w poprzedniej sekcji, pomimo prostoty wykorzystania, sposób ten ma spore wady. Aby uniknąć tworzenia Nuget.config, w kodzie źródłowym, możemy po prostu, przed budowaniem aplikacji, dodać źródło paczek nuget-a za pomocą dotnet CLI. Dokładnie tak jak to zostało przedstawione linii 9, w sekcji dotyczącej upload-u paczki do prywatnego repozytorium. Trzeba pamiętać, aby każda osoba pracująca na takim projekcie dodawała nuget-a za pomocą swojego IDE lub dotnet CLI na swoich komputerach. Wam, moi czytelnicy, zostawiam do wybrania drogę, którą chcecie podążyć.

Podsumowanie

Po zakończeniu konfiguracji wszystko już powinno działać bez większych problemów, zarówno podczas budowania aplikacji lokalnie jak i procesów CI. Jak zwykle dzięki za zaglądanie na mojego bloga, polecam zapisanie się na newsletter, aby być na bieżąco z kolejnymi artykułami. Do Następnego!