Visions In Code

Hello, dear fellow Sitecore developers!

Recently Sitecore 10.1 was released and WOW – what a release!
So many wonderful things, the konabos guys did a great post describing it all – What’s New in Sitecore 10.1
Read and be amazed 🙂

Today’s post will be about the joy of using GitHub Actions. So what are GitHub Actions?

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

See Github Actions as a light version of Azure Pipelines, here is a great post that describes them well – Azure Pipelines vs. GitHub Actions: Key Differences

The idea is this, you have a happy team of developers and they are all using Docker of course. There is a mixed variety of developers(backenders and frontenders) and computers. You want to make their life easier, especially for the “Frontenders” and those with “lesser” computers. Normally when there is a new version of the “Dev” branch, all devs have to build new images. This can be very time-consuming…
So let’s make life easier for your dev team 🙂

How about we (automatically) build images every time there is a new version of the “Dev” branch. This means that the dev team never has to build images. Just run docker-compose up -d should be enough.

So how do we do this?
Well let’s use GitHub Actions 🙂

First up is to create a .github folder in the root of our repository, and add a workflows folder to it. Here will all the GitHub actions/workflows resides.

*https://github.com/VisionsInCode/Helix.Examples/tree/feature/add-github-action

Ok great, but before we start creating our workflow(GitHub Action), which will build and push images to a docker repository. We need to decide what docker repository to use, I was thinking of trying out GitHub’s own docker repository – GitHub Packages:

GitHub Packages is a platform for hosting and managing packages, including containers and other dependencies. GitHub Packages combines your source code and packages in one place to provide integrated permissions management and billing, so you can centralize your software development on GitHub.

So in order to use GitHub Packages you need to enable it. You will do this from Settings on your organization’s profile or personal profile:

Great, you have now enabled GitHub Packages. But be aware that they are default set to Public(Public is free…). This means that any image that is pushed will be accessible for everyone and that is a big no-no for Sitecore images. Please keep that in mind. But it’s quite easy to make the packages/images private/internal, I will show you guys later 🙂

Ok 🙂 Time to build images! As always we will be using my favorite sandbox repo – Sitecore Helix Examples Repository
There is some really nice stuff here, don’t forget to switch to the “Dev” branch. You will find some very nice stuff like this one – basic-company-nextjs 😉

Asp.Net Core(or .Net 5/6) is my passion, so my favorite example solution will be – helix-basic-aspnetcore

Let’s start by creating an empty YAML file(put it under .github/workflows) and name it – BuildAndPushImages_ltsc2019. The windows version tells us that this workflow will only build images for windows version ltsc2019. VSCode has really great support for GitHub Actions, meaning the IntelliSense is wonderful when “coding YAML” 🙂

Here is the full YML file:

name: Build and push images - ltsc2019

on:
  push:
    branches: [ dev ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build-images:
      runs-on: windows-2019

      env:
        REGISTRY : ghcr.io/visionsincode/
        VERSION : dev
        OS_VERSION : ltsc2019
        COMPOSE_PROJECT_NAME : basic-company-aspnetcore
        SITEETCORE_BUILD_IMAGE : mcr.microsoft.com/dotnet/core/sdk:3.1
        SOLUTION_BUILD_IMAGE : mcr.microsoft.com/dotnet/framework/sdk:4.8
        SOLUTION_BASE_IMAGE : mcr.microsoft.com/windows/nanoserver:1809
        BUILD_CONFIGURATION : debug

        LOCAL_DEPLOY_PATH : .\docker\deploy
        LOCAL_DATA_PATH : .\docker\data
        HOST_LICENSE_FOLDER : C:\License

        SITECORE_DOCKER_REGISTRY : scr.sitecore.com/sxp/
        SITECORE_MODULE_REGISTRY : scr.sitecore.com/sxp/modules/
        SITECORE_TOOLS_REGISTRY : scr.sitecore.com/tools/
        SITECORE_VERSION : 10.1-ltsc2019
        HEADLESS_SERVICES_VERSION : 16.0.0-1809
        MANAGEMENT_SERVICES_VERSION : 3.0.0-1809
        TOOLS_VERSION : 10.1-1809

      steps:
      # Log into github registry
      - name: Log into registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      # Check out the repo
      - name: Checkout
        uses: actions/checkout@v2
      # Build the images
      - name: Build the docker-compose stack
        run: docker-compose -f examples/helix-basic-aspnetcore/docker-compose.yml -f examples/helix-basic-aspnetcore/docker-compose.override.yml build
      # List images
      - name: List images
        run: docker images
      # Push images
      - name: Push images
        run: docker-compose -f examples/helix-basic-aspnetcore/docker-compose.yml -f examples/helix-basic-aspnetcore/docker-compose.override.yml push --ignore-push-failures

Let’s go through the workflow: -)

First is the “triggering” part. Every time there is a push to the Dev branch, the workflow will start. The workflow_dispatch will let us start the workflow manually.

on:
  push:
    branches: [ dev ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

Who will run/host the workflow is next. Here we use hosted runners – windows-2019. This means the images will be built on a windows server 2019.

jobs:
  build-images:
      runs-on: windows-2019

Let’s continue with environment variables. I really like this part, it feels very “Dockerish”. Reminds me of the “.env” file when doing docker-compose stuff 🙂

env:
        REGISTRY : ghcr.io/visionsincode/
        VERSION : dev
        OS_VERSION : ltsc2019
        COMPOSE_PROJECT_NAME : basic-company-aspnetcore
        SITEETCORE_BUILD_IMAGE : mcr.microsoft.com/dotnet/core/sdk:3.1
        SOLUTION_BUILD_IMAGE : mcr.microsoft.com/dotnet/framework/sdk:4.8
        SOLUTION_BASE_IMAGE : mcr.microsoft.com/windows/nanoserver:1809
        BUILD_CONFIGURATION : debug

        LOCAL_DEPLOY_PATH : .\docker\deploy
        LOCAL_DATA_PATH : .\docker\data
        HOST_LICENSE_FOLDER : C:\License

        SITECORE_DOCKER_REGISTRY : scr.sitecore.com/sxp/
        SITECORE_MODULE_REGISTRY : scr.sitecore.com/sxp/modules/
        SITECORE_TOOLS_REGISTRY : scr.sitecore.com/tools/
        SITECORE_VERSION : 10.1-ltsc2019
        HEADLESS_SERVICES_VERSION : 16.0.0-1809
        MANAGEMENT_SERVICES_VERSION : 3.0.0-1809
        TOOLS_VERSION : 10.1-1809

The last part is the building and pushing of images:
1. Log in to GitHub so we can push our images to the GitHub Packages(docker repository).
2. Check out the code from the repository.
3. Build the images (and list the images)
4. Push the images. This part is really neat, notice we are using docker-compose push, It will do a bulk push, meaning it will try to push all images. Very nice indeed 🙂

steps:
      # Log into github registry
      - name: Log into registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      # Check out the repo
      - name: Checkout
        uses: actions/checkout@v2
      # Build the images
      - name: Build the docker-compose stack
        run: docker-compose -f examples/helix-basic-aspnetcore/docker-compose.yml -f examples/helix-basic-aspnetcore/docker-compose.override.yml build
      # List images
      - name: List images
        run: docker images
      # Push images
      - name: Push images
        run: docker-compose -f examples/helix-basic-aspnetcore/docker-compose.yml -f examples/helix-basic-aspnetcore/docker-compose.override.yml push --ignore-push-failures

Great, time to try out the workflow:

And it’s working… All images are pushed to the GitHub Packages 🙂

I mentioned before that the images/packages are public by default, so let’s make them private or internal. Click on a package and select Package Settings:

Select Change visibility:

And now you can restrict the image, keep in mind if it’s a Sitecore image it can never be public…

I have to say I’m really surprised by how easy it is to work with GitHub Actions. I am a great fan of Azure Pipelines but GitHub Actions are so easier to work with. So sorry Azure Pipelines, GitHub Actions are my number 1 tool from now on 🙂

That’s all for now folks 🙂