Day 13 - GitHub Actions

What GitHub Actions Is

GitHub Actions is another CI/CD solution.
It works similarly to Jenkins — it performs Continuous Integration and Continuous Delivery tasks.
The main difference:

• GitHub Actions works only with GitHub

• GitLab CI works only with GitLab

So before choosing GitHub Actions or GitLab CI, an organization must consider whether they will stay on that platform in the future.
If a company may move to a different platform later (like GitHub → GitLab → AWS → Azure DevOps → self-hosted Git), GitHub Actions or GitLab CI is not ideal because they are tied to their respective platforms.

Like you choose Terraform over CloudFormation because Terraform works across multiple clouds, choosing GitHub Actions makes sense only if you plan to stay on GitHub.

Even though GitHub Actions is powerful and often better than Jenkins, platform-lock-in is its main limitation.

---

Starting With GitHub Actions

You don't install plugins manually.
To use GitHub Actions, create a folder in your repository:

.github/workflows

Inside this folder, you create YAML files (your pipelines).

Example:
If you write on: push in the first line, it means:

• Whenever someone pushes a commit, run this pipeline.

It doesn’t matter what kind of commit it is—any push will trigger the workflow.

You can have multiple workflow files (10, 20, or more).
Each can handle different jobs, such as:

• Checking pull-request description

• Linting or formatting checks

• Running CI

• Running CD
  Companies often split workflows this way.

The ArgoCD project is shown as an example.
Their .github/workflows folder has multiple workflows such as CI build, code checks, PR title check, release, and security scanning.

GitHub will run any workflow whose trigger condition matches.

---

Writing a GitHub Actions Workflow

A simple Python example is used.

Inside an src folder, an addition.py program contains:

• A simple addition function

• A unit test for that function

The workflow should:

1. Run on every commit

2. Check out the code

3. Create a Python environment

4. Install dependencies

5. Run the tests

When a commit is made (adding a comment in the example), GitHub Actions automatically starts running the workflow.

The logs show steps like:

• Set up job

• Check out the repository

• Set up Python

• Install dependencies

• Run tests

• Complete job

How is this defined?

Everything is written in the workflow YAML file.

YAML formatting makes it easy (similar to Kubernetes YAML).

You define:

• Workflow name

• Trigger event

• Jobs

• Container image (Ubuntu latest)

• Multiple Python versions (e.g., 3.8 and 3.9)
  → which is why two jobs were executed

Then steps are defined:

• Checkout plugin

• Setup Python plugin

• Install dependencies

• Run tests

---

Understanding Plugins in GitHub Actions

GitHub Actions has a marketplace of plugins.
You don’t install plugins manually (unlike Jenkins).
They are available by default.

Example:
actions/checkout@v3
→ checks out the repo

actions/setup-python@v2
→ sets up Python
The number after @ is plugin version, not Python version.

The same pattern applies to Java, Node, Ruby, etc.
Only the plugin name changes.

The biggest advantage:
Very little code is needed because most work is done by plugins.

The disadvantage:
Plugins are still limited because GitHub Actions is newer compared to older tools like Jenkins.

---

Self-Hosted Runners

In GitHub repository settings, you can add self-hosted runners.

You may need this if:

• GitHub’s default runners are too small

• You need more compute for tasks like load testing

• You need internal security/compliance

Then the workflow runs on your own machines instead of GitHub’s machines.

---

Secrets Management

GitHub Actions allows securely storing secrets, such as:

• kubeconfig

• Sonar token

• Passwords or keys

These can be used inside workflows.

The Java + Maven + Sonar + Kubernetes example demonstrates this.

---

Comparing GitHub Actions with Jenkins

Disadvantage

GitHub Actions is platform-dependent.
If you move from GitHub to another platform (GitLab, AWS CodeCommit, Azure DevOps), your GitHub Actions pipelines cannot be reused.

Advantages

1. No hosting effort

   • No need to install Jenkins, setup EC2 instances, configure plugins, or maintain servers.

2. Less maintenance

   • No managing Jenkins updates or plugin compatibility.

3. Simple UI and easy pipeline creation

   • YAML based, plugin-driven, easy to understand.

4. Cost

   • Free for public repositories

   • Limited free minutes for private repositories

   • Still cheaper than maintaining Jenkins infrastructure

Because of this, ~90% of open-source projects prefer GitHub Actions.

---

Final Summary

GitHub Actions is an easy, plugin-driven CI/CD solution built for GitHub.
It is great when your codebase will stay on GitHub.
It removes maintenance overhead, provides free execution for public repos, supports secrets, supports custom runners, and is simpler than Jenkins.

However, it locks you to GitHub.
If your organization might switch to another platform, GitHub Actions is not ideal.