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:
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:
The workflow should:
Run on every commit
Check out the code
Create a Python environment
Install dependencies
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
No hosting effort
- No need to install Jenkins, setup EC2 instances, configure plugins, or maintain servers.
Less maintenance
- No managing Jenkins updates or plugin compatibility.
Simple UI and easy pipeline creation
- YAML based, plugin-driven, easy to understand.
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.