#Tendências em tecnologia

Use GitHub Actions to automate your process

I’m a Microsoft MVP, and community guy focused on DevOps and for now, I’m a specialist in Azure DevOps. I loved when Microsoft launched the GitHub Actions and started to study/test them.  After I played with them for a long time and did so many tests, videos and talks about this, I now understand how important and how powerful the GitHub actions are. In this article, you can see how it’s working and how to create a first action.

How It’s working

GitHub Actions work an easy way, using Yaml scripts and versions with its source code. The Actions is so flexible too, for example, you can run your pipelines in all OS platforms, like Windows, Linux and MacOS, using GitHub hosted runners or your self-hosted runners.

Instead your thoughts, it’s working with a lot of scenarios, for example, you can run your deployment in Azure, AWS, GCP, your OnPremisses environments too.

The amazing thing in Actions, is the flexibility that we must run only CI/CD, but a lot of other things, for example:

  • Push
  • Commit
  • Fork
  • Issues
  • Branch
  • Deployment
  • Label

With this in mind, you can see how powerful the actions are, and how many things you can automate in your repo.

The action scripts, for default, are maintained on “./github/workflows” folder.

Creating a new Action

If you decided to create a new GitHub Action, you need to navigate to Actions option in your repo. In this window, you can see the last runs of your actions, or create a new workflow. If it’s your first time in action on repo, you see by default, a Get Started window, with a lot of templates for use.

When you start to setup a new workflow, a new window with a starter script is open, you can see your script, and the marketplace and documentation to create your own CI pipeline using GitHub Actions.

Action Default Structure

All of actions pipelines, have a same structure on scripts, for example:

 

  • Name: the name of your pipeline
  • On: the trigger of this action run
  • Jobs: the jobs with this action run.
  • Runs-on: the Runner with you.
  • Steps: the tasks and steps to run in your pipeline.

Triggers

Triggers are the method to run your pipeline, and you can run this with a different scenario like we saw in this article before. This step is very important because using the correct trigger, your pipeline knows the correct moment to run, and automate the steps correctly.

If you decide to run your pipeline when the branches master or any release branch was committed, you need to put your trigger like this image:

You can set up the trigger to run scheduled to, for example, in this image, your workflow will run every day of the week, from Monday to Friday at 2:00 UTC.

Or for example, if you need to run your pipeline if an issue is been created or changed, you need to do this:

You really run your pipeline with a lot of different type of events.

Runs-On

Runs on are the method to choose where your pipeline runs, for example, if you like to run in ubuntu or windows. In GitHub Actions you have some runners for use, these runners are:

  • ubuntu-latest
  • ubuntu-18.04
  • ubuntu-16.04
  • windows-latest
  • windows-2019
  • macos-latest
  • macos-10.15

 

To select your runner, you need only to inform the runner name on runs-on like this image.

If you decide to run using your own runner, you need to install him, and in the pipeline, you’ll need to inform the name like a “self-hosted”.

You have another option to run your pipeline. Imagine if you are developing a .Net Core application, and need that this one  compile in Ubuntu, Mac and Windows, you don’t need to maintain tree pipelines, you can use only one pipeline, but run the same pipeline in all of this options. To do that you’ll need to use the Matrix concept.

In this example, we have a matrix to run in three different agents and three different versions of node. In this case, this action will be running each time with each OS version and Node version.

Steps

Steps are the method to run specific tasks to run your pipeline. For example, if you like to compile your .Net Core Application, you need to run a .net restore, .net build and .net publish. In this scenario, you’ll have at least three tasks to run it. In GitHub Actions, you can have a lot of steps, as many as needed to run your pipeline correctly.

The steps are like this image:

Marketplace

GitHub has a great marketplace for extensions and actions. If you need any action for your pipeline, you can look at the marketplace to search for this.

In the Marketplace you can find a lot of actions from GitHub and from other developers and companies. If you don’t find a specific action for you, you have two options: 

  1. Create your own action
  2. Use the script task to run your specific script step.

If you decide to create your own Action, you can share this with the community to other people or companies.

Configuring your first Action

Now, we are creating our first action on repo, we need to access the Actions menu >  Set up a workflow yourself.

For this action, we will use the ubuntu-latest runner, and the trigger will be pushed on the branch master.

The steps, we will be use:

  • Checkout@v1
  • Setup-dotnet@v1
  • Run
    • This is a generic step to run commands.

To configure the .Net Core CI, we need to put the steps Checkout and Setup .Net, and after this, we need the run tree commands:

  • Dotnet restore
  • Dotnet Build –configuration Release
  • Dotnet Publish –configuration Release -o netcore

 

If you did all steps correctly, you script will be like this:

Don’t forget to save your action.

Now, every time you have a new commit on master branch, the new workflow will be running like this.

If you click in one of these execution items, you can see all the logs of this execution, and if your CI fails you can understand what happened with your application.

I really hope this article will help you to start to work with GitHub Actions and automate your CI and other processes more easily.