Github Actions: Power of CICD

#github #cicd #devops #actionshackathon

Github has been improving continuously to provide a better experience to its users. The recent update of Nov 19 Github's actions was introduced. By Introducing Github actions developers now have the power of CI/CD and version control in the same dashboard.

CI/CD is the heart of automation. Github now provides a one-stop solution for maintaining, building, documenting, testing, and deployment of code. It is so convenient to have the code and CI/CD pipelines in the same place. I remember changing tabs to see if the build has passed in Travis CI and having to maintain a separate dashboard. Which with the introductions of travisci.com has made it even more difficult to track. My old repository builds are not even automatically imported from .org to .com. And there were other issues like ghost repositories build whose name has been changed or deleted.

Github's actions is also a better solution than Jenkins's pipeline. I would prefer an automated and freely available hosted server for my CI/CD pipeline than a fully user-managed installation on my local computer.

So what is Github action

Github is more than CI/CD it is a general-purpose workflow system for building and testing or doing pretty much anything you want to do with your code after you push it to the repository.

We can automate and execute different workflows right from our repository with Github actions.
Being an opensource project you can find pretty much everything as an already implemented repository either by Github or some other third party repository. If we want to deploy to AWS there is a workflow for that. If we want to publish to GitHub pages there is a workflow for that. We can even run a CRON job, for instance, so if you want to update your static webpages every two hours? there is an implementation for that too.

What is a workflow?

So the workflow is what makes all of this possible. It is the string that holds all the beads together. We can compare a workflow with Spring batch, It made up of different jobs which in turn has actions. We can choose to create a workflow of our own or can use an already existing workflow provided by Github or any other third party repository.
A single workflow can consist of various different jobs that can be executed parallelly or one after the other based on the configuration we define. So if we want to deploy our application after a successful build we can have the deploy be dependent on the build job.

#Build.yml

name: Build using Github Workflow   # Specifying the name of the workflow

on:                                 # This acts as the trigger 
  push:                             # and lets GitHub know when to trigger the job
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:                               # This lets us define the various 
  build:                            # jobs we need to execute for a successful build
    runs-on: ubuntu-latest          # Specifing the image to run our code on
    strategy:
      matrix:
        node-version: [10.x, 12.x, 14.x] # Specifying the runtime
    steps:                          # Steps are actions that are to be performed
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install --production
      - run: npm ci
      - run: npm run build --if-present
      - run: npm test

Above is one of a typical workflow file that defines how we want to build our application. For Github to automatically detect and start building our application we need to put our configuration file in .github/workflows directory

So what can be done using Github Workflow

Github workflow provides the developer with an arsenal of events to have a trigger on. We can trigger a job on not just push or pull requests but pretty much anything event in the Github ecosystem. This level of flexibility provides us with tremendous potentials. We can have a job to treat a new contributor, we can check for stale issues and pull request, We can build using macOS, Windows, and Linux simultaneously as parallel build jobs.

The UI of Github actions is a piece of art, we have live streaming logs that are color-coded and have emoji support as well, yes you heard it right 'emoji' support. We can search in the entire logs for errors and keywords. Suppose you have an error in the logs, now if you want to share that error you just need to copy an already provided URL for the exact line of log containing the error. Now no more "line number 12 of blah blah", just copy the URL and share it to friends, peers and it will take you to the exact line where the error is.

We can also generate badges saying build passed or failed and use it in our readme file to let other contributors know.

A good thing about these workflows is that they are nothing but repositories that can be referenced from anywhere, which means no pre-configuration is required to use actions present somewhere in the whole Github ecosystem. We just need to reference it and done we can extend the functionality.

Now if you want to deploy your application on cloud, Github has support for almost every cloud out there and actions to take help from. We can always create our own actions from scratch as well. Now what about my credentials, don't worry now every Github repository comes with a secret store where you can secretly store your credentials and reference it in the workflows. I mean what else do we need. By the way, these builds are absolutely free for all open source projects.