Bar Programming #02 - How to use GitHub Actions to provide an environment with CI

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:

---
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.

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

And finally, make a pull request:

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

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

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