CI/CD with GitHub Actions

 If you are working with GitHub Actions, you might too get confused with the term Workflow vs Actions. Here I’m gonna explain the difference as well as also giving you example to create your first CI/CD, even if you have never done it before.

GitHub Actions

In Github, Actions is the entire platform which automate the build, test and deployment pipeline. That means in GitHub, we create an Actions to automate our CI/CD pipeline.

The GitHub Actions consists several components as:

1. Events
2. Workflows
3. Jobs
4. Actions
5. Runners

Actions is the component of GitHub Actions, aah this is confusing. Also if you notice in the github UI, you will see as:

Here with the help of a simple GitHub Action which will just build the project and run Tests, we will discuss about above mentioned components and also clear the confusions/doubts too which arises due to naming as we talked.

Our requirement is: Create a GitHub action to build the project and run the test and will call it “Build and Test workflow”. Workflow, because GitHub calls it as workflows which is a GitHub action consisting all components as we defined above.

Since all our GitHub actions are shown under workflows in UI, lets convince our mind to call the action as ‘workflow action’ to avoid confusion (fair enough) and to do this add a folder named as .github/workflows in your project repository and follow the steps:

Step 1: Create a .yml/.yaml file in .github/workflows folder and name it as build-and-run-tests.yml.

.github/workflows/build-and-run-tests.yml

Step 2: Create the workflow.

Workflow is all the tasks which has to be performed when the event (in our case, push event on the branch repo) occurs.

In other words these are the pipelines which performs the task like build (build pipeline), Tests (test run pipeline).

As workflow syntax concerns, it consists of name (name of the workflow), on (event for workflow to trigger) and jobs (tasks to perform).

For the first, here we create the .yml or .yaml (no other extension is recognized/allowed) and name the workflow.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'

In this file we name the workflow action as ‘Build and Run tests’ and added a variable available to this .yml file only.

Step3: Create an Event .

An Event is something that happens in a GitHub repository. i.e. Push, Create, delete, deployment, fork, pull_request, workflow_dispatch etc.

This is our first component of GitHub action workflow.

So now we define the ‘on’ part of the workflow which will trigger the workflow whenever there is push to our GitHub repo:

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:

Here we say, whenever Push event occurs on master branch trigger the action workflow. I also used the action workflow_dispatch which allows user also to manually trigger the workflow action.

Step 4: Create Jobs to perform tasks.

A Job is a series of steps inside the workflow which are executed. Each step is either a script to be executed or an action that would run.

Note: Steps are executed exactly in the order they are defined and dependent on the previous step being complete. So if previous step fails and the next step will not be executed.

So as per our requirement, we will create a job, to build and run tests.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
   environment: Test

in above code, we created a job called build pipeline and defining the environment as ‘Test’ to use to look for secrets if I uses within the pipeline as ${{secrtes.MySecrets1}}, this you can can define from settings tab.

Separating secrets with environment is useful when you have multiple jobs for dev, test and production etc within a single workflow action.

Step 5: Define the Runners.

The Runners are the process on the server that runs the workflow. Runners are hosted in the cloud and we specify the name of the runner for job using runs-on syntax.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
    runs-on: windows-latest
    environment: Production

Every job can have only one runners and in our case we specified as ‘windows-latest’ and the rest will be taken care by GitHub engine.

By now, theoretically our workflow action is ready doing nothing. So lets add the step to build the project and run the test as steps of the job ‘build’ as per our example requirement.

name: Build and Run tests#define variables
env:
 DOTNET_VERSION:'6.0.x'on:
  push:
    branches:
      - master
  workflow_dispatch:jobs:
  build:
    runs-on: windows-latest
    environment: Production    steps:
      - uses: actions/checkout@v2      - name: Set up .NET Core        
        uses: actions/setup-dotnet@v1        
        with:          
          dotnet-version: ${{ env.DOTNET_VERSION }}       - name: Build projects
        run: |
          dotnet build --configuration Release      - name: Test with the dotnet CLI
        run: dotnet test

In above code, we have added 4 steps, out of which 1st step is for checkout the git repository and the other steps are as their name says.

Note: Based on your project structure you may have to define path of the .csproj/.sln in your repo for dotnet build and test command to run.

If I need to picturize the whole things, the way it works as:

Hope you enjoyed the content, follow me for more like this and please don’t forget to like/comment for it. Happy programming.

Bonus

Follow me here for my next article on CI/CD with GitHub Actions to deploy Application to Azure App Service