Github actions in the action

In recent months, we have started to use Github more actively. There are several reasons. We started developing our own shareable libraries, we started creating internal tools, and so on. This led to several further steps and decisions. We have become a Github organization. So nice news. The second idea was to save our time when developing multiple tools so that we could test the tools, write nice code, and deploy them. Github has a very cool solution for these issues. They call it Github actions.

What do we use it for?

We use for example ESLint in our applications, or we write tests using JestJS, and of course, we automate to build and deploy to the production stage.

If we had to do these steps manually, it would take us a long time. However, we save a lot of time with Github actions.

Let me invite you to show you a very basic workflow of how we use Github actions.

1. step – Master branch is a production

Whatever you push to master branch means, that it is also in your production build that users are using.

For developing, create a new branch called for example develop. Every time you are coding, use this branch or checkout a new one from this development branch. It is because your code does not have to be bugless. To master branch, try to push all the stuff only if you are sure that everything works correctly.

2. step – Creating workflows

In your project folder in root, create a new folder named .github with a subfolder named workflows.
In workflows folder, all you need is create .yml files named by action or workflow for which it will serve.

For example, if you would like to create an automated workflow for linter, you can create file lint.yml.

Then, your structure will look like this:

3. step – Writing workflows

Let’s take lint.yml workflow. Before we start to write code, we have to realize what it will use for.

As the name of the file suggests, we will use it to check if our code has a correct structure according to the set rules. Also, we need to say, when the code will be checked – let’s say every pushed commit and created a pull request. The last thing what we need to realize is, what happens then.

name: Lint
on: [push, pull_request]
    runs-on: ubuntu-latest
    - uses: actions/checkout@v1
    - name: Install dependencies
      run: npm install
    - name: Run lint
      run: npm run lint

In the workflow file, we need to name the workflow (Lint). Keyword on means, when the. action will be triggered. The last things are jobs, in these steps you write a workflow to achieve a result.

3.1 step – Production only

In the first step, we said that we will use master branch only for the production state. But, in our lint.yml workflow, we mentioned nothing about master branch. How to set up automatization every time you push code to this branch?
You have to say when and where the action will be triggered.

      - master

What does it mean? Every time you do push to branch master, something will happen. This action is very good and recommended for automated deploy.

4. step – Check if everything works

If you have everything pushed to Gihub, actions will be recognized by Github automatically and a new tab called Actions will be added.

After every commit or pull request, it depends on how you set it up, you will see the health status of your code, tests, deployment, and so on.


Github actions solve a number of problems that the programmer would not have to do manually. They are adjustable, customizable and the developer can easily adapt them to his project. They are also suitable for beginning programmers who experiment with automation. They do not have to pay for expensive tools and can quickly learn the process of automation or other procedures.

We like Github action, there are definitely things that could be improved, but so far they suit us and we recommend trying them out.

We hope this article has brought you at least a small amount of new knowledge.

#actions#auto deploy#automatization#CI/CD#github
WRITTEN BYPatrik Mäsiar