GitHub Actions Made Simple: A Beginner’s Guide to CI/CD Automation

In this post, I will discuss GitHub Actions terminologies and break them down so beginners can dive in easily. What is GitHub Actions? GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. Imagine a scenario where you have an application deployed to a server, for example, AWS. After deployment, you need to update and push that update to the server. This would be a lot of work without automation. This is where GitHub Actions comes in. It simplifies the entire process for you, including tasks like building, testing, and redeployment. Knowledge Required to Get Started with GitHub Actions Must-Have: Basic Git skills: Understanding git clone, git add, git commit, git push, git pull, branching, etc. Understanding the GitHub interface: Basic actions such as creating a repository, navigating branches, and creating pull requests. YAML syntax: For writing workflows. Optional Skills: Shell scripting: For automation. Understanding project workflows: To manage tasks efficiently. Basic troubleshooting skills: To debug issues during workflow execution. CI/CD concepts: For faster and more efficient delivery. Docker: For containerization (see Learn Docker in Plain English). Table of Contents Workflow Event Runners Actions Jobs Workflow A workflow is a configurable automated process running one or more jobs. In simpler terms, it is a mapping of instructions written in a .yml or YAML file that instructs GitHub Actions on executing the developer's desired tasks. Think of it as a manual or guide for GitHub Actions to follow. Workflows are defined in a repository's .github/workflows directory. A repository can have multiple workflows, each performing different sets of tasks. Naming Conventions: The naming convention for your workflow file should match its purpose. For example: Good: run-tests.yml (clearly indicates the workflow is for testing). Bad: my-workflow.yml (generic and lacks context). When You May Need a Workflow: Continuous integration. Deployments. Automation. Code scanning. Automated testing. Event An event is a specific activity in a repository that triggers a workflow run. Events are actions like git push, git merge, git commit, opening an issue, or creating a pull request. For a full list of events that can trigger workflows, refer to the GitHub documentation on events. Runners A runner is a server that runs your workflows when they're triggered. This is essentially the computer that hosts your deployed application and executes the GitHub Actions defined in it, such as an AWS Linux server. Actions An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Think of actions as the building blocks of a workflow. If a workflow is a mansion, actions are the components and materials used to build it. For example, in a workflow, you can have: An action to change the directory. An action to check the directory's permissions. An action to execute the build process. Jobs A job is a set of steps in a workflow that are executed on the same runner. Each step is either a shell script or an action to be run. Difference Between Actions and Jobs: Actions: The individual building blocks of a workflow. Jobs: Groups of actions executed on the same runner (server). With this basic knowledge, you should be ready to dive into GitHub Actions! I hope you find this content useful. Please note that this is just scratching the surface of the iceberg. To dive deeper into GitHub Actions, refer to the official GitHub Actions documentation. The official documentation is always the best place to learn from.

Jan 18, 2025 - 05:47

GitHub Actions Made Simple: A Beginner’s Guide to CI/CD Automation

In this post, I will discuss GitHub Actions terminologies and break them down so beginners can dive in easily.

What is GitHub Actions?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. Imagine a scenario where you have an application deployed to a server, for example, AWS. After deployment, you need to update and push that update to the server. This would be a lot of work without automation. This is where GitHub Actions comes in. It simplifies the entire process for you, including tasks like building, testing, and redeployment.

Knowledge Required to Get Started with GitHub Actions

Must-Have:

Basic Git skills: Understanding git clone, git add, git commit, git push, git pull, branching, etc.
Understanding the GitHub interface: Basic actions such as creating a repository, navigating branches, and creating pull requests.
YAML syntax: For writing workflows.

Optional Skills:

Shell scripting: For automation.
Understanding project workflows: To manage tasks efficiently.
Basic troubleshooting skills: To debug issues during workflow execution.
CI/CD concepts: For faster and more efficient delivery.
Docker: For containerization (see Learn Docker in Plain English).

Workflow
Event
Runners
Actions
Jobs

Workflow

A workflow is a configurable automated process running one or more jobs. In simpler terms, it is a mapping of instructions written in a .yml or YAML file that instructs GitHub Actions on executing the developer's desired tasks. Think of it as a manual or guide for GitHub Actions to follow.

Workflows are defined in a repository's .github/workflows directory. A repository can have multiple workflows, each performing different sets of tasks.

Naming Conventions:

The naming convention for your workflow file should match its purpose. For example:

Good: run-tests.yml (clearly indicates the workflow is for testing).
Bad: my-workflow.yml (generic and lacks context).

When You May Need a Workflow:

Continuous integration.
Deployments.
Automation.
Code scanning.
Automated testing.

Event

An event is a specific activity in a repository that triggers a workflow run. Events are actions like git push, git merge, git commit, opening an issue, or creating a pull request.

For a full list of events that can trigger workflows, refer to the GitHub documentation on events.

Runners

A runner is a server that runs your workflows when they're triggered. This is essentially the computer that hosts your deployed application and executes the GitHub Actions defined in it, such as an AWS Linux server.

Actions

An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Think of actions as the building blocks of a workflow. If a workflow is a mansion, actions are the components and materials used to build it.

For example, in a workflow, you can have:

An action to change the directory.
An action to check the directory's permissions.
An action to execute the build process.

Jobs

A job is a set of steps in a workflow that are executed on the same runner. Each step is either a shell script or an action to be run.

Difference Between Actions and Jobs:

Actions: The individual building blocks of a workflow.
Jobs: Groups of actions executed on the same runner (server).

With this basic knowledge, you should be ready to dive into GitHub Actions! I hope you find this content useful. Please note that this is just scratching the surface of the iceberg. To dive deeper into GitHub Actions, refer to the official GitHub Actions documentation. The official documentation is always the best place to learn from.