Avoid GitHub Actions!

📝 TLDR: Don’t use GitHub Actions as it’s overcrowded with unnecessary
abstractions and False sense of security. Use GitLab CI as the most transparent
CI ever existed.\
🎥 Check out the video we created:

Introduction

Back in 2014 I started to poke around GitLab CI.
At the time GitLab was pretty new and they just recently added that feature 🚀.
It looked very logical and structured ⚙️:

• Place the .gitlab-ci.yml file inside of the repository;
• Define the jobs which are simple shell scripts and on each commit your pipeline is triggered and script runs;
• Check the results in a nice Web UI;

Pretty straightforward. This was my first encounter with CI/CD systems.

GitLab CI

For the past 10 years I’ve encountered many other CI systems.
Some of them were straight legacy like Jenkins or Buildbot
some others were simple clones of Travis CI

🤫 Psst:GitLab CI actually was heavily inspired by Travis CI

such as CircleCI or Drone CI.
But these systems are cumbersome to manage.
Eventually we always end up using GitLab CI.

Late to the Party

While we were using GitLab CI in many different ways I always wondered why
GitHub didn't introduce any CI system as it was such a logical thing to do.
And they did in 2018! Meet Github Actions. Almost 4 years later.
You might be wondering if they did a breakthrough in
Continuous Integration space.
Unfortunately no 🤦.
They took the same approach using YAML as base
and placing jobs inside of the repository.

Me Me Me… Me too!

For the past 6 years I’ve never had a chance to actually try Github Actions
in "Action" (pun intended).
Quick glimpse on the syntax did show that it looks
very similar to repo YAML based CI systems - but syntax is quite abstract and
not very transparent.

“Ok… Then… Nothing that hard… But still very strange…” - I thought 🤔

The Action!

At one sunny summer day of 2024 I was forced to do a rather simple workflow
that I did hundreds of times using GitLab CI:

• Build Docker image;
• Push image to Container Registry;
• Deploy image using HELM Chart to Kubernetes cluster;

“Nothing complicated.” - I thought 😃
But this is where the fun starts.

Fun #1

Abstractions… Abstractions… and more abstractions.
In order for the pipeline to work and do simple things I needed to understand
a lot of wrappers around simple tools that I use on a daily basis.
Some genius thought It’s a good idea to create “actions”.
They require you to code the “action” in the separate repository.

🤯 Why? Why? ...

Docker build and push for example. This is a simple
one shell command that does all of this. You don’t need to abstract that thing.
That is overcomplicated.

Fun #2

It seems that in order to push/pull Docker image to GitHub Container Registry
I need to use my Personal Access Token 🤬 GitHub doesn’t provide native way
to create a simple Deploy Token that isn't bound to a GitHub user account.
So by simply removing a user from repo you break access from Kubernetes
to GitHub Container Registry 🫤

Fun #3

It also was a shocking thing 😱 to me that when a Secret is added to
the Repository it's impossible to view it and change after.

“It is for the SECURITY!” - you might shout ‼️

But in reality this is not security - it is dumb! ☹️

Any DevOps/Developer with access to the cluster or app who understands
how CI/CD works and the workflow can extract these secrets without any problem.
For the professional it’s not a problem it's just an inconvenience.

Conclusion

I’ve managed to get it working but still… So much hassle.
I will never ever agree to work with GitHub Actions.

On the bright side - GitLab is still the best and gives you simple
and transparent tools to do your development.

Use Gitlab for god sake‼️

Source: https://blog.wiregate.io/posts/avoid-github-actions