Github Actions - budowa obrazów Dockerowych i wrzucenie ich do repozytorium - Damian Szymczuk

W poprzednim wpisie pokazałem w jaki sposób zbudować i przetestować aplikację z wykorzystaniem Github Actions. Czas na kolejne workflow, na którym zmarnowałem bardzo dużo czasu. Dlaczego? Zapraszam 🙂

W tym wpisie dowiesz się:

Spis treści

Pushowanie obrazu przez Github Actions – plik yml
Analiza pliku yml

Pushowanie obrazu przez Github Actions – plik yml

name: Push docker images

on:
  push:
    tags:
      - 0*

#defaults:
#  run:
#    working-directory: ./api

jobs:
  Build-Docker-Images:
    runs-on: self-hosted
    timeout-minutes: 20

    steps:
      - uses: actions/checkout@v2

      - name: Get the version
        id: get_version
        run: echo ::set-output name=SOURCE_TAG::${GITHUB_REF/refs\/tags\//} #${{ steps.get_version.outputs.SOURCE_TAG }}


      - name: Login to Docker Repository
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}
          registry: ${{ secrets.DOCKER_REPOSITORY }}


      - name: Set up Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@v1


      - name: Cache Docker layers
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-


      - name: Build Docker Image - API
        uses: docker/build-push-action@v2
        id: docker_build_api
        with:
          file: api/dockerfiles/api/Dockerfile
          context: ./api
          push: true
          builder: ${{ steps.buildx.outputs.name }}
          build-args: |
            PM2_PUBLIC_KEY=${{ secrets.PM2_PUBLIC_KEY }}
            PM2_SECRET_KEY=${{ secrets.PM2_SECRET_KEY }}
          tags: |
            ${{ secrets.DOCKER_REPOSITORY }}/my-app/my-app-api:${{ steps.get_version.outputs.SOURCE_TAG }}
            ${{ secrets.DOCKER_REPOSITORY }}/my-app/my-app-api:latest
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache-new

      - name: Images digest
        run: |
          echo ${{ steps.docker_build_api.outputs.digest }}

#      - name: Run APP on Jenkins
#        uses: appleboy/jenkins-action@master
#        with:
#          url: "URL_JENKINS"
#          user: "USER_NAME"
#          token: ${{ secrets.JENKINS_TOKEN }}
#          job: "JOB_NAME"

Analiza pliku yml

Tam razem plik yml jest dłuższy.

Linijka 3-6
Tym razem będziemy uruchamiać akcję na każdego taga, zaczynającego się od 0 – aplikacja jeszcze nie jest oficjalnie gotowa, dlatego po wypuszczeniu wersji 1 będę musiał zaktualizować plik.

Linijka 8-10
Zakomentowany kawałek. To właśnie ten kawałek mnie przez kilka godzin mylił. Albo dał nauczkę, aby czytać dokumentację. Ten fragment ustawia working directory tylko dla polecenia run.

Linijka 20
Niestety, mimo, że to repozytorium Githuba nie ma prostego sposobu na pobranie i wykorzystanie nazwy branch’a czy tagu. Wielka szkoda! 😒
Rozwiązań jest mnóstwo, powyże zaprezentowane jedno z kilku. W komentarzu zapisałem sobie sposób jak tag został zapisany, aby wykorzystać go w kolejnych krokach.

Linijka 25-30
W przypadku tej aplikacji nie korzystam z Docker hub. Mam postawione własne repozytorium i na nim hostuję swoje. Niezależnie czy korzystasz z własnego czy Docker hubowego repozytorium, musisz się zalogować.

Linijka 33-44
Konfiguracja buildera oraz cache. Nie będę ukrywał, że na ten moment zrobiłem copy-pastę i nadal te polecenia, jak działają.

Linijka 47-62
Tutaj się dużo dzieje 😃
Zwrócę uwagę na parametr file. Ścieżka musi bez bezwględna od roota naszego projektu. To właśnie tutaj spędziłem kilka godzin (chyba z 4 czy 5 🙄), ba! nawet zgłosiłem issue do wtyczki, że nie uwzględniają working directory. Okazało się, że nie wiedziałem jak działa ustawienie working directory.
Mea culpa.
Do zbudowania aplikacji potrzebne są zmienne środowiskowe. Należy je oczywiście skonfigurować wcześniej jako sekrety naszej aplikacji. Pozioma kreska (linijka 55) oznacza polecenie wielolinijkowe. Dzięki temu możemy w czytelny sposób skonfigurować sobie zmienne potrzebne do budowy naszej aplikacji.

Linijka 64-66
Wyświetlam sobie hash naszego obrazu.

Linijka 68-74
Zostawiam ten fragment dla osób, które korzystają z Jenkinsa. W wpisie Github Actions czy Jenkins? Czy warto korzystać z Github Actions? napisałem dlaczego korzystam z Jenkinsa do deploymentu.
Aplikacja nie jest jeszcze gotowa na Continuous delivery, dlatego kod czeka na odkomentowanie 🙂

Github Actions – budowa obrazów Dockerowych i wrzucenie ich do repozytorium