Today I’ll start with GitHub Actions

Gisela Torres
DevOps
June 13, 2020

I have been playing with GitHub Actions for several days, testing different scenarios that I have been able to find in other automation tools, such as Azure DevOps or Jenkins. In this article I want to tell you about the minimum you should know to start managing your continuous integration and deployment tasks with this platform.

 

New Actions section on GitHub  

It is possible that if you already worked with GitHub you have noticed that, for a while, you have a new section called Actions.

In it you will see that there are different templates for different programming languages ​​called workflows,which give you a starting point for the integration or continuous deployment of your applications. You can explore the ones with which you feel most comfortable with, in terms of technology, but I want to show you something more elaborate at a glance

 

Structure of a workflow

If you have clicked on any of the templates proposed in the Actions section, you will see that GitHub bases its flows on files in YAML . When you save any of these templates they are stored in. github / workflows.

In order to better explain the structure,you should use, I am going to show you this example, which compiles and deploys an example application with .NET Core (and Blazor). It comes from the Blazor: Getting Started by Gill Cleeren course, in Azure App Service:

 
  
name: Build and deploy the web app
on:
  push:
    branches:
      - master
    paths:
      - 'BethanysPieShopHRM.server / **'
      - '.github / workflows / build-and-deploy-web-app.yml'
env:
  WEB_APP_NAME: bethanyspieshopblazor
jobs:
  continuous-integration: #name of the job
    runs-on: windows-latest
    steps:
    - uses: actions / checkout @ master
    - name: Set up .NET Core
      uses: actions / setup-dotnet @ v1
      with:
        dotnet-version: '3.0.103'
    - name: Build with dotnet
      run: dotnet build --configuration Release
    - name: dotnet publish
      run: dotnet publish -c Release -o $ {{env.DOTNET_ROOT}} / webapp
      working-directory: ./BethanysPieShopHRM.server
    - name: Upload artifact
      uses: actions / upload-artifact @ v1
      with:
        name: webapp-artifact
        path: $ {{env.DOTNET_ROOT}} / webapp
  continuous-deployment:
    needs: [continuous-integration]
    runs-on: windows-latest
    steps:
    - name: Download artifact
      uses: actions / download-artifact @ v1
      with:
        name: webapp-artifact
        path: $ {{env.DOTNET_ROOT}} / webapp
    - name: Login via Azure CLI
      uses: azure / login @ v1
      with:
        creds: $ {{secrets.AZURE_CREDENTIALS_BLAZOR_RG}}
    - name: Add some settings
      uses: azure / appservice-settings @ v1
      with:
        app-name: $ {{env.WEB_APP_NAME}}
        app-settings-json: '$ {{secrets.APP_SETTINGS_WEB_APP_WINDOWS}}'
    - name: Deploy to Azure Web App
      uses: azure / webapps-deploy @ v1
      with:
        app-name: $ {{env.WEB_APP_NAME}}
        slot-name: 'production'
        # publish-profile: $ {{secrets.WebAppPublishProfile}}
        package: $ {{env.DOTNET_ROOT}} / webapp
    - name: Azure logout
      run: |
       az logout

 

As you can see in the previous code, a workflow has 4 fundamental parts: a name, an event / s that triggers it, the declaration of environment variables (optional) and the jobs that will be executed. Let's see each section separately:

name

This is the name of the workflow, in order to be able to differentiate it from other flows that you have in the same repository.

 
  
name: Build and deploy the web app
 

As the list grows, it is very useful to have an identifying name for each one.

 
  
on
 

This property is essential as it will be used to indicate what this flow will launch on.

 
  
on:  
              push:    
                            branches:      
                                          - master  
    paths:      
                                          - 'BethanysPieShopHRM.server / **'      
                                          - '.github / workflows / build-and-deploy-web-app.yml'

 

As you can see, it can be executed thanks to the push event, amongst many others that I will tell you about, on specific branches, and it can even depend on the changes that have occurred in the specified routes through paths. In this example, the flow will only be launched for the master branch, but only when a change has occurred either in the workflow file itself or in any of the files within the BethanysPieShopHRM.server directory.

 
  
env
 

This section is not mandatory but it is very useful for declaring environment variables, which will be available globally for the duration of the flow, even between different agents.

 
  
env:  
              WEB_APP_NAME: bethanyspieshopblazor

 

jobs
 

As its name suggests, this section will define the different jobs that make up the flow. Each of them will have a name, runs-on identifies the type of runner (agent) you need to execute the tasks and a series of steps (steps) that will be carried out as part of the job.  

 
  
jobs:  
              continuous-integration: #name of the job    
  runs-on: windows-latest    
  steps:    
                - uses: actions / checkout @ master    
    - name: Set up .NET Core      
    uses: actions / setup-dotnet @ v1      
    with:        
                  dotnet-version: '3.0.103'    
    - name: Build with dotnet      
                  run: dotnet build --configuration Release    
    - name: dotnet publish      
                  run: dotnet publish -c Release -o $ {{env.DOTNET_ROOT}} / webapp      
      working-directory: ./BethanysPieShopHRM.server    
    - name: Upload artifact      
                  uses: actions / upload-artifact @ v1      
    with:        
                  name: webapp-artifact        
                  path: $ {{env.DOTNET_ROOT}} / webapp

 

Within each of the steps you can see different actions: those executed through run, which are just commands, or those that use predefined actions, through uses. Several are used in this snippet:  

  • actions/upload-artifact@v1: used to create artefacts based on files or directories specified in that action. They are normally used so that another job can download it and make use of it. This example generates an artefact with the result of the project compilation.

Finally, look at the second job:

 
  
continuous-deployment:    
              needs: [continuous-integration]    
  runs-on: windows-latest    
  steps:    
                - name: Download artifact      
                  uses: actions / download-artifact @ v1      
      with:        
                    name: webapp-artifact        
        path: $ {{env.DOTNET_ROOT}} / webapp    
    - name: Login via Azure CLI      
                  uses: azure / login @ v1      
                  with:        
                    creds: $ {{secrets.AZURE_CREDENTIALS_BLAZOR_RG}}    
    - name: Add some settings      
                  uses: azure / appservice-settings @ v1      
      with:        
                    app-name: $ {{env.WEB_APP_NAME}}        
        app-settings-json: '$ {{secrets.APP_SETTINGS_WEB_APP_WINDOWS}}'    
    - name: Deploy to Azure Web App      
                  uses: azure / webapps-deploy @ v1      
      with:        
                    app-name: $ {{env.WEB_APP_NAME}}        
        slot-name: 'production'        
        # publish-profile: $ {{secrets.WebAppPublishProfile}}        
        package: $ {{env.DOTNET_ROOT}} / webapp    
    - name: Azure logout    
                  run: |      
                                 az logout

 

This is going to be in charge of the deployment. For this to be possible, it will depend on the previous job,which generates the package to be deployed. The dependencies of other jobs are set with the needs property, where you can specify one or more jobs for which it must wait to be executed. If nothing is specified, both jobs would be executed in parallel, so the latter would fail as the artefact was not ready.

Here other actions than the previous ones that are used:

  • actions/download-artifact@v1: allows you to download the artefact generated in the previous job.
  • azure/login@v1: starts a session throughAzure CLI in your Microsoft Azure subscription, since in this example the deployment will be done in an App Service.
  • azure/appservice-settings@v1: add values ​​in the configuration of this Azure service (depends on the previous action, since you need to login before).
  • azure/webapps-deploy@v1: carriesout the deployment. In this example I have commented on the possibility of doing the same using the publish-profile option. If you don't need the above task, which adds settings in the service, you can use the publish profile instead of Azure CLI.

These last two actions, in addition to using environment variables, are also making use of secrets: secrets.AZURE_CREDENTIALS_BLAZOR_RG and secrets.APP_SETTINGS_WEB_APP_WINDOWS.These are configured in the Settings section of the repository, in the Secrets section:

Once saved in this section, it will not be possible to view its content again.

Predefined actions for your workflows

As you have seen in the example,the workflows are made up of jobs and these are made up of steps. Although you could define all the steps using scripting, there is a marketplace with more than 32,000 actions that you can use for your flows.  

Gisela Torres

Gisela Torres works at Microsoft as Cloud Solution Architect. It is a technical position whose mission is to support and advise on cloud solutions and architectures using Microsoft Azure as a platform. Prior to that I work as a software architect and application developer in several companies. During those years he received several awards such as Most Valuable Professional in Microsoft Azure. He loves programming and technology in general.

Keep Reading

Newsletter EuropeClouds.com

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form