Bar Programming #02 - How to use GitHub Actions to provide an environment with CI
Tags: beginners, tutorial, devops, learning
Published: 2024-03-06 15:00:00

Today, I will write a basic guide to understand and use GitHub Actions.

First, we have a YAML file, in this file we have all the configurations about our automation. This file specifies, Events, Jobs, Runners, Steps and Actions.

---

But, before we go to GitHub actions, we need to understand when this code will run. In GitHub actions, we have "**triggers**".

An event is a trigger in our workflow, with this, we can understand when something to happened, an example is a “push”. 

---

For use the GitHub Actions, you have to create a YAML file in a folder name `.github/workflow`, in this folder you create something like myWorkflow.YAML

An example of a YAML file:

```YAML
---
name: Lint

on:  # yamllint disable-line rule:truthy
  push: 
    branches: [main]
  pull_request: 
    branches: [main]

jobs:
  build:
    name: Lint
    runs-on: ubuntu-latest

    permissions:
      contents: write
      packages: write
      # To report GitHub Actions status checks
      statuses: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          # super-linter needs the full git history to get the
          # list of files that changed across commits
          fetch-depth: 0

      - name: Super-linter
        uses: super-linter/super-linter@v6.2.0  # x-release-please-version
        env:
          # To report GitHub Actions status checks
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VALIDATE_CHECKOV: false
          
...
```

Now, an explanation of the things you read:

- **name** is the name of your workflow, but, this is optional
- **on**, is where you select the triggers. In this case, we will listen to the push and pull request. 
- **branches**, this is which branch you will listen to
- **jobs**, this is your task, you will test your code? Verify the style of code?
- **build**, this is the recipe of your build, the steps. 
- **permissions**, this defines how much access the workflow will have.
- **steps**, and finally, this is the steps of your process.
- **name (inside of steps)**, the name of this step.
- **uses**, this is used to add a pre-existing action to your workflow, simplifying and reusing code.
- **with**, allows you to pass parameters and settings to the action you are including, customizing its behavior.
- **env**, defines environment variables that can be used at any step in the workflow.

---

Obs: In your YAML, you have to put more attention to your code indentation.

---

With this, when you or a college make a push or a pull request, the GitHub will be tested for you.

Now, I will show for you where and how to make this. 

I will use this [repository](https://github.com/ThomasLincoln/myGitActions).


![Repository](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p73p1umo01golckrnaro.png)

Now, I will add a file without any indentation and bad code style.


![Creating File](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/x616g9bpp1vcomuote3r.png)

And finally, make a pull request: 


![Pull Request](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m6m52xcymw79qhozwuye.png)



![Test Running](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mjzmztmk0bweluh8l7cb.png)


Now, you can see the test running, and if all run how I expected:


![Error in pull request](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3uy3qi3pjhcx9lyqrbdj.png)

We have some errors in our linter workflow, and if you want to know what and where, just click in details: 


![Error details](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rt3xvtwni715boehd309.png)

By resolving the error, we received positive feedback, so you can run automated tests before accepting a pull request, or before merging your branches.

![Bye](https://media1.tenor.com/m/xvo8-YQ78P0AAAAC/porky-pig.gif)