GitHub Actions basics - Event, Workflow, Runner, Job, and Action ⚙️
Tags: github, devops, beginners, todayilearned
Published: 2022-04-08 02:46:38

## What is GitHub Actions? 🍀

![GitHub Actions tab](https://cdn.hashnode.com/res/hashnode/image/upload/v1649368701631/KjZsDJwvC.png)
I guess you are familiar with the GitHub at this point. Is it more than a version control system to you? As you can see in the image, there is an `Actions` tab which leads to the **GitHub Actions** feature. What is it, you may ask?

**GitHub Actions** is an automation platform that contains **workflows**, and the workflows can be triggered manually, on schedule, or based on different **events**. It can create a CI/CD pipeline to build, test and deploy your codebase. However, as a mature automation platform, it can run arbitrary system commands, so its capability is *NOT* limited to a CI/CD pipeline.

In my previous article [Advanced GitHub Actions - Conditional Workflow](https://hungvu.tech/advanced-github-actions-conditional-workflow?utm_source=dev.to&utm_medium=referral&utm_campaign=devto_crossposting), I dived into the advanced feature. This time, let's start from the ground and discussing the basic concepts of GitHub Actions.

## GitHub Actions anatomy 🍀

![Components of GitHub Actions](https://cdn.hashnode.com/res/hashnode/image/upload/v1649373965048/k3ExcTcW5.png)

GitHub Actions consists of 5 core components:

1. Event
2. Workflow
3. Runner
4. Job
5. Action

How are they related? An **event** triggers a **workflow**, which contains multiple **jobs**. A **runner** executes a job, and one job can have multiple **actions**. By the way, I'm not certain why one component is named *action* while the platform is already named *GitHub Actions*, that just sounds confusing. 🤦‍♂️ 

### What is an event? 🔑

Whenever something happens, it is an event, literally. You may wonder what can be considered **events** in GitHub Actions, and here, we have 2 types of events.

1. Repository events
   These are the events within the scope of your repository. Some notable examples are *creating a pull request* and *merging code*. It can go to the atomic level of how you use GitHub on a daily basis. You can take a look at [GitHub Docs to learn more about available events and their usage](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows).

2. External events
   These are what happens outside of your repository. By using a webhook event called [`repository_dispatch`](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch), you can trigger a specific workflow.

### What is a workflow? 🔑

This is something "big" that you want to achieve, a configurable automated process defined by a `yaml` file that resides in the `/.github/workflows` folder. Do you want an end-to-end test process? It can be named `e2e workflow`. An example of the MUI repository below might give you a better visualization of GitHub Actions workflow feature.

![MUI repository' workflows](https://cdn.hashnode.com/res/hashnode/image/upload/v1649377966521/nTSK5d9Y8.png)

### What is a runner? 🔑

It is a virtual machine (Linux, Windows, Mac) with an application called [GitHub Actions Runner](https://github.com/actions/runner) running. A runner will run a job when a workflow is triggered. The runners can be either self-hosted for customizability or GitHub-hosted. 

A job can specify its runner using a `runs-on` property. As each job uses its own runner (fresh virtual machine), their environment data is isolated by default. However, you can share the data by explicitly passing variables or results between them.

**Note**: I find the definition of a runner to be confusing. In some places, its purpose is defined as to run a *job*, however, other places say it runs a *workflow*. I believe they mean the same thing (as defined above), but you can keep this in mind and double check if necessary.

> "The runner is the application that runs a job from a GitHub Actions workflow. It is used by GitHub Actions in the hosted virtual environments, or you can self-host the runner in your own environment."
>
> -- [<cite>GitHub Actions Runner README</cite>](https://github.com/actions/runner#github-actions-runner)
>
>
> "A runner is a server that runs your workflows when they're triggered."
>
> -- [<cite>GitHub Docs</cite>](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#runners)

### What is a job? 🔑

In GitHub Actions workflow, there are jobs that consist of sequential (and skippable) steps. You can think the job as a group of tasks to do in order to achieve a goal (workflow). Each step defines a specific operation to be executed, be it a script, an GitHub Actions *action*, or arbitrary system commands.

Due to a sequential nature, a step is dependent on the previous one. If a previous step modifies an environment, then the later steps are affected by the changes. If one step fails or execute an `exit` command with a failed-signal, the workflow will be cancelled.

![MUI workflow](https://cdn.hashnode.com/res/hashnode/image/upload/v1649381586908/ypdUHzjUr.png)

### What is an action? 🔑

If a job is a group of tasks, then an action is a task. An action is a repetitive and complex in nature that is created using languages that can be compiled to JavaScript or using bash script in a container. There is [a whole marketplace that you can a suitable action in there](https://github.com/marketplace?type=actions).


![GitHub Marketplace.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1649382851473/PIR0n50qj.png)

## Wrap up 🍀

Hopefully this helps you learn more about components of *GitHub Actions* platform. This article is only a brief introduction to this massive feature. You can learn more about this by using [an official GitHub Docs](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions). That said, I think I will write some more articles to have a deeper dive into this feature.