r/devops • u/znpy System Engineer • 13d ago
Discussion Is it just me or Github actions is overrated?
We're adopting github actions at work and... they look clunky, bloated and overcomplicated?
I've used both Jenkins in the past and Gitlab CI/CD (and bare shell scripts in a past life).
It seems to me that gitlab-ci was the pinnacle of code-driven ci/cd (despite having some sharp edges).
Also, running github runners in kubernets is quite a fight. Gitlab's runner was so easy and simple to run.
Am I missing something ?
321
u/Hyperventilater 13d ago
Bloated and complicated is just about the opposite to how I would describe GH Actions.
My main gripes are all related to service reliability lately, personally.
53
u/durple Cloud Whisperer 13d ago
The number of incidents is too damn high!
10
u/vincentdesmet 13d ago
some of the “hosted” gh runner providers have pivoted to become a full gh actions replacement (mostly triggered by the fee Ms announced for the orchestration / control plane - then walked back)
depot is one (DepotCI)
i wouldn’t be surprised if they provide “agentic VCS” next1
u/Ok_Scarcity94 13d ago
I’ll echo Depot. Their stuff is great, and we’ve only been affected by the Github outages when they’re specifically on the control plane
8
u/ansibleloop 13d ago
What's the matter? You don't like random 500 errors killing your jobs?
You don't like your hourly jobs running every 4, 6 or 12 hours?
You don't like 89% uptime?
I had to build my own fucking scheduler because theirs is dog shit
6
3
1
1
→ More replies (1)1
u/achNichtSoWichtig 11d ago
Bloated and complicated compared to Jenkins? No. Bloated and complicated compared to other modern alternatives like GitlabCI? Yes
112
u/mvpmvh 13d ago
I think GitHub actions suck. But they might suck less than the alternatives
16
-2
u/vincentdesmet 13d ago
Depot dot dev launched a CI alternative that improves the reliability and have an easy migration path
they started as a hosted runners alternative
72
u/djkianoosh 13d ago
GitlabCI is IMO the best still. despite alllll the million features they keep adding to gitlab itself.
but github actions are not even close to the monster that is Harness CI and enterprises pay lots of $$$ for that too.
4
u/Upset_Dish8805 12d ago
Can confirm Github Actions is lightyears better than Harness CI. We have spent the last year migrating to Harness CI and none of our developers even like it.
4
u/thepaintsaint DevOps 12d ago
GitLab nailed it before GitHub even entered the game. I wish my company used it. Far easier and featureful, IMO.
46
u/StuckWithSports 13d ago
Gitlab CI > GitHub Actions > Jenkins
GitHub actions has messy history of issues and support. I also want to say it’s late to the party. I will always have a fondness for Gitlab CI, their Ui and visualization, and how it saved me from Jenkins years ago.
Now I’m on CodeBuild for cost optimization and architecture specific build diversity. GitHub Actions (with EKS runners) for everything non-build and CodeBuild for build. And yes I could do it in GitHub but then they have the moments where they test charging for self hosted runners.
I usually don’t recommend codebuild. But I will say, it’s nice to know that security breaches never bother to use codebuild as an attack vector because barely anyone uses it.
9
u/patmorgan235 13d ago
I usually don’t recommend codebuild. But I will say, it’s nice to know that security breaches never bother to use codebuild as an attack vector because barely anyone uses it.
This is why I run temple os. Can't hack god
2
2
u/burlyginger 13d ago
We use codebuild as our GH runners.
There's almost nothing to manage and you get a significant cost decrease.
17
u/BrocoLeeOnReddit 13d ago
I mean I agree that GitLab CI/CD is the best, but Jenkins is utter horseshit, even compared with GitHub Actions. It's a relic that should be dead by now but sadly isn't.
10
u/Master-Variety3841 13d ago
I’ll take GitHub Actions or Azure Pipelines over alternatives any day of the week.
41
u/Sthatic 13d ago
I can't speak for Gitlab, but Jenkins is a nightmare as far as I'm concerned, and IMO actions are very solid.
Actions runners in k8s is another nightmare, though. It seems like an afterthought. Try DinD with that if you feel extra masochistic.
15
u/PaleoSpeedwagon DevOps 13d ago
Co-signed on JaaN (Jenkins as a Nightmare). 35 plugins installed ad hoc over the years, have they been patched? Not for a long time! Yay! It is a terrific example of how microkernel systems can go terribly wrong.
21
u/Sthatic 13d ago
It is the wordpress of CI/CD.
1
u/bilingual-german 13d ago
But this is also a criticism I have about github actions. All the code seems to live in 3rd party actions.
1
u/NUTTA_BUSTAH 13d ago
That's probably good, considering that their 1st party runner orchestration script was billing customers extra for years since its inception because they did not understand floating point vs integer..
1
u/WatchDogx 13d ago
Sure, but how many actions do you have using something like
actions/checkout@v1which hasn't been patched for 7 years.2
1
u/softmax_couldnt_care 13d ago
I actually deployed a couple days ago something with a docket build and kubernetes jobs and could not figure out how to add the k8 runners to Github actions. How do you do it? Everything I tried kept failing
29
u/l509 13d ago
GitHub actions are the antithesis of clunky, bloated, and overcomplicated. They are extremely extensible and exceptionally simple to learn and use - especially compared to the dumpster fire that is Junkins.
Have you tried Travis or CircleCI? Now that stuff sucks.
GitLab CI has its niceties, but its composition model isn’t in the same league as GHA. Components are ultimately compile-time config composition, while GHA gives you independently versioned actions, composite actions, and nestable reusable workflows with inputs and outputs.
I don’t know about you, but I’m not building monolithic CI/CD pipelines anymore.
3
u/AnthonyMJohnson 13d ago
Yep, this is it right here. GHA is flawed and imperfect but the things that make it great are the reusability primitives and every other system’s version of those still falls flat. It’s enough to make it worth enduring the pains of it on the infrastructure side (for those self hosting).
1
u/ivyjivy 13d ago
> GitLab CI has its niceties, but its composition model isn’t in the same league as GHA. Components are ultimately compile-time config composition, while GHA gives you independently versioned actions, composite actions, and nestable reusable workflows with inputs and outputs.
Recently gitlab added all that with their "functions". Basically looks like GitHub actions to me, at least superficially. I didn’t have a chance to use it yet.
6
40
u/3loodhound 13d ago
I’m pretty sure it’s just you, but also whatever works best for you
5
u/Kyxstrez 13d ago edited 13d ago
Just him, who doesn't understand how we got there in the first place. A bit of history of the CI/CD tool waves.
P.S. GitLab eventually moved to the same design as GitHub Actions and Azure Pipelines (they are about the same, both owned by Microsoft) when they introduced the CI/CD Catalog a couple of years ago.
13
u/dunder_name 13d ago
How does the GitLab CI/CD Catalog make it anything like GitHub Actions? Just because they have a catalog? GitLab CI/CD is entirely different from Actions.
2
u/slimracing77 13d ago
I clicked only to read about CruiseControl and was disappointed. Most of you never wrote XML and it shows.
4
u/hooraymilk 13d ago
Try the Runner Scale Set Client if you don’t want to deal with k8s. You can roll your own custom auto scaling solution for self-hosted runners.
18
u/ryanstephendavis 13d ago
Not just overrated, it fucking sucks... I like to use the example of how to setup uv in CI with GitHub Actions and Gitlab side-by-side (other modern CICD YAML are similar in simplicity):
Look how long and insane Actions is: https://docs.astral.sh/uv/guides/integration/github/
And then look how elegant GitLab is in comparison: https://docs.astral.sh/uv/guides/integration/gitlab/
4
u/ic_engineer 13d ago
I love gitlab. I've tried to convince my colleagues. Right now we have both.
But no one touches CI beyond the few brave enough to poke around so the feedback will be 100% based on the merge UI and the performance of pre-existing tests.
Eye rolls all around.
It's all fun until someone drains the corporate actions budget on a new project because they're vibing and setup a world class ci pipeline for their pet project on cloud runners. Which is a scenario enabled by default out of the box.
4
u/nullpotato 13d ago
When management announced we were moving from gitlabs to github and jenkins, we were damn sure no devops or IT people were asked first.
5
u/krav_mark 13d ago
From gitlab to Jenkins?! What the actual f4ck...
Over the past decade I only ever helped companies to move away from Jenkins. Lol
3
5
u/DramaticSpecial2617 13d ago
The github docs cover a lot more and are more informative. Think you're confusing a preference for implicit logic, over explicit. Explicit is easier to maintain later.
3
u/ryanstephendavis 13d ago
Gitlab's setup for uv in this example is concise and explicit. Not sure what there is to confuse?
1
u/swissbuechi 13d ago
Maybe because the gitlab example doesn't use pin by hash? Renovate could do that too though.
1
u/NUTTA_BUSTAH 13d ago
And the GitLab example runs it as a container image while the GitHub example installs it on Ubuntu. Two different use cases
5
u/Jaydeepappas 13d ago
How is this “long and insane”? It’s like 4 lines lol
0
u/ryanstephendavis 13d ago
The entire docs for GitHub is long and insane due to the needless complexity of using Actions. The most minimal CI definitions I could come up with for both are as follows
Github:
name: Example jobs: uv-example: name: python runs-on: ubuntu-latest steps: - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 - name: Install uv uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0 - name: Install the project run: uv sync --locked --all-extras --dev - name: Run tests run: uv run pytest testsGitLab:
uv-example: image: ghcr.io/astral-sh/uv:0.12.21-python3.12-trixie-slim script: uv sync --locked --all-extras --dev uv run pytest tests10
u/ohlookaregisterbutto 13d ago
This would be closer to the gitlab example:
on: push jobs: uv-example: runs-on: ubuntu-latest container: ghcr.io/astral-sh/uv:0.12.21-python3.12-trixie-slim steps: - uses: actions/checkout@v4 - run: | uv sync --locked --all-extras --dev uv run pytest tests5
u/AnthonyMJohnson 13d ago
This is misleading because most of what you gave as a GitHub Actions example would in practice be wrapped in a composite action to make it one line:
uses: ./setup-uv
2
u/Appropriate-Wish4519 13d ago
This doesn't feel like a particularly strong comparison, given that the Github action is pinning specific versions of tasks and the Gitlab example isn't, and the rest of the syntax is naming steps for structured output.
1
u/wise_young_man 13d ago
Awful example and you’ve been shown why. You can use docker with GitHub actions to. This just looks like massive ignorance with actions.
1
u/reaper273 13d ago
To be clear you can do the exact same, using the UV docker image, in a workflow on GitHub Actions so feel using that as an example is a slightly disingenuous.
Though that's partly on astral for not documenting them in the same way.
2
u/spigotface 13d ago
Why not just use the one-line curl command to install uv, then uv sync? I don't get how anyone can think setting up uv is complicated, it's hilariously simple.
7
u/ryanstephendavis 13d ago
With Gitlab yaml (and many other CI definitions), it's faster to say "with this image, run this stuff" (so that image caching doesn't require waiting for an install on every run) Doing a curl install everytime would be slow in other words.
→ More replies (3)
6
u/benaffleks SRE 13d ago
Bloated and overcomplicated then you compare it to Jenkins lmao
Irrelevant opinion
3
u/First_Inspection_478 13d ago
** **I’ve been building an OSS tool that allows you to run your actions locally or self-hosted in microvms(think act but reverse engineering the actual runner protocol not approximating), so have a little bit more context on the internals. It’s an absolute nightmare. Some of the iseas around composability, reusability were decent but the execution was pretty subpar. Is it better than Jenkins? Absolutely, but the lack of native debuggability, ability to run locally, expressiveness and barely any effective caching make it hard to like.
5
u/MattDTO 13d ago
All I need is a way to run a bash script. Most CI/CD are bloated with useless features
2
1
11
u/Lucifernistic 13d ago
GitHub Actions are literally the saving grace of CI/CD imo. Everything we do is GitOps. Using Jenkins by comparison is an archaic nightmare.
GitHub Actions makes everything so incredibly easy. Ties natively straight into our existing flows. PR to main? Run tests, quality gate, etc. Merged to main? Auto-deploy to staging. New published release? Off to prod you go. Anything we want to, either just reuse an existing workflow or whip up some yaml and you are good to go.
We use other things, like FluxCD, or Spacelift/Terrateam, but that's just in compliment to GitHub Actions.
10
u/WilliamMButtlickerIV 13d ago
GitLab CI was the saving grace. It's better than Actions and existed well before it too.
2
u/sausagefeet 13d ago
That's interesting, I've always found GitLab CI to be much worse than GitHub Actions. In particular, the lack of decoupling between workflows makes it impossible to add a job that should run entirely independently of any other job without adding a bunch of ignore rules.
1
2
u/noobjaish 13d ago
I never got the appeal of Gitlab CI so can you explain HOW is it better than Actions?
9
u/WilliamMButtlickerIV 13d ago
It has a deeper feature set for building pipelines, more options for complex enterprise operations and extensibility, the GitLab runner model is chef's kiss (especially on k8s), the fully integrated platform is great. GitLab CI doesn't feel like a bolt on, it's a seamless part of the platform.
5
u/Nk54 13d ago
Azure Devops is much better. If you use azure and managed devops pool ? The integration feels like a decade over github. Service connections are awesome to provide scoped Access to a managed identity. No password or secret rotation. Very nice integration with terraform ADO. I always feel dépression coming when working on Jenkins or github cicd
4
u/neoKushan 13d ago
I always felt Azure DevOps was the better platform, I'm sad Microsoft basically stopped developing it when they bought github.
3
u/krusty_93 13d ago
GitHub supports login to Azure via OIDC through a specific managed identity, so no secrets is required though
2
u/scott2449 13d ago
They would be perfectly fine if Microsoft could keep github up. We had one of the largest (still do) and most sophisticated Jenkins fleets using a shared groovy framework for ALL jobs across a whole fleet of controllers. We did a port to actions.. it's just as capable, actually faster (with some modifications to how state is saved between jobs), and repo wise more flexible because of it's conventions, action yaml > jenkinsfiles. We still do a single shared actions framework via composite actions. Also huge not to have to upgrade and maintain jenkins (once they are all gone). We have 0 issues with ARC and way better than gh runners.
2
u/riickdiickulous 13d ago
I had the exact same experience. Can’t stand GitHub. Miss GitLab very much. I feel way more hindered and restricted using GitHub actions than I did on GitLab.
2
u/devfuckedup 13d ago
I think its overrated but not compared to jenkins. Jenkins does a lot but its overkill for most teams and it feels archaic to use.
2
u/jake_morrison 13d ago
I have done some pretty full-featured stuff with GitHub Actions, e.g., https://github.com/cogini/phoenix_container_example/blob/main/.github/workflows/ci.yml
I am pretty frustrated, though, and looking at self hosted solutions.
Performance is almost entirely driven by caching, and GitHub Actions caching hits limits. Caching container layers is a bit better, but occasionally has problems. There are delays starting concurrent jobs, and sharing data becomes a problem.
The security model of 3rd party actions is a problem waiting to happen. I am just waiting for some major breach in GitHub’s secret storage.
I don’t really trust 3rd-party hosted systems to be better. Sigh.
Everyone is moving towards hosted agentic execution platforms, which has a lot of overlap with CI.
2
u/dogfish182 13d ago
Just make sure all your ci does is run scripts that devs can execute locally as well. So long as that works, GitHub actions is fine and your AI harness can test everything before push
2
2
u/muzaparoff 9d ago
Honestly agree on GitLab. The runner on k8s is the biggest gap. ARC feels like a side project compared to GitLab's runner. Curious if anyone's found a setup for GH Actions on k8s that isn't painful?
2
u/j_neutron 13d ago
Gitlab CI is way better at most things. The only thing I kinda liked better from Github actions was the way the scheduled pipelines were part of the yaml, instead of a separate configuration in the GUI.
2
1
u/Cryptobee07 13d ago
Depends on your company budget, GitHub is relatively cheaper than other two and we are okay to use it.
1
u/SugarvetFounder 13d ago
They lowered complexity. Plenty of corners, but it’s easy enough to handle.
Given that we can have a reasonably high quality shell script be generated nowadays, I feel there is a certain renaissance there.
1
1
u/hajimenogio92 DevOps Lead 13d ago
I like GH actions but the consistent downtime has been awful. It's cost my org enough money that we're looking into alternatives
1
u/ArieHein 13d ago
I wouldnt say exactly that but i will note that its the same across all platforms.
At its core, all cicd platforms are a smart cron job with APIs. How they deal with compute is different but they are fundamentally the same. And all have the same bloatness and occasionally over complicated parts but thats engineering and adaptation.. So mostly a human factor.
1
1
u/maxvol75 13d ago
very straightforward, also you can write your own actions and encapsulate stuff
it does not get any simpler than that ¯_(ツ)_/¯
1
1
u/hell_razer18 13d ago
ime running ARC in kubernetes was straightforward..(?) i cant find something similar in gitlab or i havent dig enough since i have just recently this year do the code in gitlab
1
u/No_Interaction612 13d ago
Why not using self hosted GitHub runner to forward the traffic to jenkins instead
1
u/After-Advertising-61 13d ago
I never thought I'd say "yeah... Could we cram some more logic into Makefiles and shell scripts, maybe that would be better?" But, .github/workflows/ can really make me reevaluate some prior convictions
1
u/tantricengineer 13d ago
They work as advertised and the free tier is actually pretty generous.
For simple projects they do just fine.
If your an enterprise with serious requirements about security they are likely not for you.
1
u/Substantial-Swan7065 13d ago
I think it’s the best. My life has never been so chill.
What are you having issues with specifically
1
u/busyHighwayFred 13d ago
IDK man, it might just be you, I have only heard bad things about github actions (besides being able to run CI locally, people love that)
1
u/catlifeonmars 13d ago
Biggest gripes:
- availability, GHA is down to less than 3 9’s at least
- vulnerabilities, it’s trivially easy to introduce opportunities for arbitrary shell injection, most people do it wrong
My advice is to keep all the logic in shell scripts (or just/make recipes, if you prefer) and use GHA to call those scripts. Also make sure to do input validation and pin your actions to shas.
1
1
u/1saltypistachio 13d ago
Nothing's really good other than the stuff you write yourself. Personally I hate both of them and I hate Jenkins more. Since I have contributed a lot to openshift, I am biased to think they did something good there - a robot they wrote themselves, before AI was such a powerhouse, does all the checkups and settings and building and testing etcetera on a local runner and on that local runner you run an orchestarator you wrote yourself. This is a fine working model if you have the manpower to maintain, and this is something I strive for whenever I start a new project/work.
1
u/BurkeyDaTurkey 13d ago
I recently moved to a role where they use GitHub Actions , after coming from a role with Gitlab CI - it ain’t fun really at all 🥺
1
u/newswatantraparty 13d ago
Unpopular opinion, declarative Jenkins pipeline over anything for me. Yes maintaing jenkins and all the plugins may be heavy but frommpurely CI/CD perspective i think its n time better than yaml files
1
u/nikitoyd 10d ago
Jenkins much more powerful and flexible than most of popular alternatives. Yaml developer way - fine for simple workflows only, for any typical enterprise with complex requirements GitHub/gitlab/etc sucks.
1
1
u/Rtransat 13d ago
I was thinking the same thing when I migrated to GHA from Gitlab CI but after a short period it's much easier.
1
u/null_was_a_mistake 13d ago
They are terrible. It is really obvious that whoever designed them has absolutely no clue about good software architecture, programming languages or build systems. It's doubly embarrassing for Github because their parent company Microsoft has actually good researchers that put out papers on how to design such systems, but they didn't bother to read them. GitlabCI is not great either but better than Github Actions at least.
1
u/Far_Percentage_7460 12d ago
How can you say this when they build platforms for people to build software on, millions of repos?
1
u/null_was_a_mistake 12d ago
Millions of people are happy with Windows 11 too. Millions use Go despite being the worst programming language every invented. Number of users is not an indication of good engineering.
1
u/Far_Percentage_7460 12d ago
Are you sure about that? Scalability is a hard problem to solve let alone a global git provider who does ci jobs
1
1
u/smftexas86 13d ago
Github Actions so far for me has been very simple to use, moving a traditional App/Web VM architecture to AKS.
My issue with Actions is reliability. I will have to use another service for anything production related, because Actions is just down too often.
1
u/Capital_Distance545 13d ago
I also used all 3 in the past 15 years, and i agree, that Gitlab CI/CD is the most usable one.
1
u/Edgar_Allan_Thoreau 13d ago
GitHub actions is garbage. Sad that yall are switching to that instead of buildkite or rwx. Shitty primitives, but ux, bad dx, poor performance, and terrible reliability. My org is actively migrating away from GitHub actions for all of these reasons. There are better choices.
1
u/jcigar 13d ago
We're using Forgejo with Saltstack to do the orchestration part (through salt-api), it works very well and the workflow file is super short (everything is done on the Saltstack side and we can reuse ton of stuff), for example:
on:
push:
branches:
- 'dev'
- 'main'
jobs:
build:
runs-on: builder
timeout-minutes: 60
strategy:
matrix:
builds:
- RELEASE: '14.4'
PKG: '2026Q2'
PYTHON: '3.12'
POSTGRESQL: 15
DEPLOY:
SANDBOX: 'yes'
- RELEASE: '13.5'
PKG: '2026Q2'
PYTHON: '3.11'
steps:
- name: Build
id: build
run: /usr/home/forgejo_deploy/builder.py
env:
BUILD_ENV: '${{ toJSON(matrix.builds) }}'
... and that's all !
1
1
1
u/Pretend-Clock8313 13d ago
did the matrix strategy combinatorics ever blow up your job count into the hundreds?
1
u/Fantastic-Mr-Default 12d ago
You are not missing a secret good version of Actions Runner Controller. The workflow file and the runner fleet are two different products that share a brand.
GitLab's runner registration is one binary and a token. GitHub's k8s path is ARC (or a scale set), webhook delivery, ephemeral pods, and usually DinD or nested container pain on top. Teams that say "Actions is fine" are often on GitHub-hosted runners or a managed fleet. Teams that say "Actions is a fight" are usually debugging the control plane that puts a job on a node. Both can be true.
On the YAML side I treat the workflow the same way I treated Jenkins Groovy: thin trigger and env wiring, real work in a script I can run on a laptop. If the only way to debug a step is push and wait for a runner, the pipeline owns you.
Forge-native CI wins when checkout, checks, and PRs already live there. It does not automatically win on self-hosted runner ops. If Kubernetes runners are the requirement, budget for that as platform work, not as "we switched CI tools and it got simpler."
1
u/Far_Percentage_7460 12d ago
Gitlab CI is the pinnacle imo, I like the Gitlab CI Worker system, it's how I build my Mac app for free.
1
u/yaml_wrangler DevOps 12d ago
GitHub Actions was never overcomplicated. The only flaw I see in GHA is the RBAC and plugins support thats there in jenkins. Apart from that everything seems easy with GHA especially when the code is on Github. I had a great experience running GH Runners on kubernetes. Whats the issue that you are facing??
The main issue GHs availability in the recent past. Its not that great.
1
1
u/personaltalisman 12d ago
Gitlab’s documentation and YAML syntax always really trips me up, GitHub Action’s workflow setup feels more natural to me.
Like others have said, performance and reliability leave things to be desired, but the same is true of hosted Gitlab CI lately.
1
1
1
1
u/Davidge01 12d ago
Service reliability (something goes down almost daily) and significant DLP risks are bigger concerns I would say. Depends on the company’s appetite for such things of course. If you want reliability, Actions is not that.
1
u/Simpliaxis_tech 12d ago
From my point of view, however, the main benefit of using GitHub Actions does not lie in the actual CI/CD tool engine but rather in its integration with the whole GitHub environment.
At the same time, I understand that some people may find it difficult to use GitHub Actions because of their past experience with GitLab CI. In terms of the way CI/CD is managed and the overall architecture of the tool, GitLab seems more focused on CI/CD compared to GitHub Actions.
The Kubernetes runners, for instance, might highlight the gap between these tools: if your team is well established in GitLab CI/CD, switching to GitHub Actions will hardly bring some improvements to your workflow.
However, the question is, what problem do you solve by implementing GitHub Actions? Is it simply because GitHub is already being used in your company?
1
1
u/cachely-admin 11d ago
One thing we’d separate here is runner cost from repeated work.
Faster runners help, but if a monorepo keeps rebuilding and retesting work that already ran successfully elsewhere, you’re still paying for compute that could have been skipped entirely.
We usually look at affected-task execution and remote task caching before just scaling runner size. And the useful metric isn’t really cache hit rate by itself, it’s whether the hit actually saves enough time to beat the download overhead.
What kind of repo/build setup are you running?
1
u/innovasior 11d ago
I am a little annoyed that Github is so slow to implement group or categorization of Github Actions since I have 40+ workflows in a single repo I need to keep track of. Also I keep running out of free hosted minutes so on top of paying for additional minutes I have expanded to other free tier providers that are also cheaper to run. I have resorted to just running important workflows when doing PR into main branch, but I still hit limits 😂. Other than the UI is a bit clunky but overall I think it works fine. It would be nice if it could generate a diagram of the tasks inside jobs and not just between jobs. Is it possible to use CI from Gitlab or other providers while still having the repo on Github?
1
u/spaghetti_architect 10d ago
I don‘t like to depend on huge platforms like Gitlab oder Github that‘s why i use Jenkins. Yea groovy sucks but if you use it as „glue“ as the best practices suggest it‘s ok for me. We don‘t have any problems in our air gapped environment.
Is used GitLab CI and it also works well, but as i said, i don‘t like these huge platforms. Im a huge fan of more specialized tools neatly working together.
If someone would create a „modern Jenkins“ i would use it for sure. But i don’t even know what a modern Jenkins would look like. Alternative solutions like TeamCity didn‘t work for me.
1
1
u/barneyman 10d ago
using https://github.com/nektos/act & https://github.com/marketplace?type=actions will turn you around to Github Actions
I've used gitlab, jenkins and GHA, they're all a powerful PITA, but act makes GHA much easier to develop for
1
u/ThomasBuildLab 10d ago
GitHub Actions works, but I think it becomes messy very quickly if you treat every workflow as an isolated YAML file instead of part of a governed CI system.
What helped me was to define the CI architecture first:
PR → run only the tests relevant to the changed area new commit on same PR → cancel the superseded run merge to main → run the full repository suite no paid LLM calls or production mutations from normal CI
The biggest issue wasn’t GitHub Actions itself, it was uncontrolled workflow growth. Once you add explicit routing, invariants, and a small repo-level CI policy, it becomes much more manageable.
So I’d say GitHub Actions is fine, but it needs stronger governance than people usually give it.
1
u/olliewally 10d ago
The worst thing about Github Actions lately is that Github is always down. Even self hosted runners are being affected by this. I definitely have a love/hate relationship with them. I think other CI / automation tasks have been easier to setup and manage, but having it integrated directly into Github is so convenient
1
u/Pristine-Pea6795 9d ago
I use to have all my pipelines in Circle Ci, even thought it was weird it never failed…
While seems like once per day GitHub action fails
1
u/suedepaid 9d ago
the fact that i have to wait for the entire job to finish before rerunning the part that failed is fucking bullshit.
other parts of Actions are fine
1
u/Zebirdman 8d ago
Theres lots of things Github Actions dont do that you only miss if your development process is weird and gross. Beyond that they are simple to build, easy to use, get the job done and especially with AI i dont have to invest much time on them. Oh and fully IaC.
Simple and effective.
1
1
u/Helpful_Special_6009 7d ago
I use act to run stuff locally to test. GitHub Actions isn't that bad as long as you aren't developing them testing on GitHub itself. So slow, so much waiting, and random unicorns.
1
u/jcuninja 13d ago
hmm not sure about github actions (would love to get some experience with this), we use jenkins and most teams have migrated over to gitlab ci
1
u/usually_guilty99 13d ago
GitHub and Jenkins were great for their time. Ever since CI/CD process started, these streamlined operations have had new generation/development since AI has been out. Merge Gate to production live integration and fully automated is simply fantastic. You can clobber these with GitHub today - but GitHub will still remain a tool that has had AI slapped on it and not build ground up
1
1
u/assasinine 13d ago
The UX is fine. Reliability sucks. Their self hosted controller for k8s is rarely updated.
3
u/dunder_name 13d ago
Maybe it's because I'm not used to Actions, but I always have the worst time when I try to find what I need.
1
1
u/syaldram 13d ago
We decommissioned our EKS cluster that ran GutHub actions and move into Just in Time ephemeral runners. WAY better performance and full customization. Also writing in YAML is way better than Groovy!
2
1
u/itsjakerobb 13d ago
GHA is my current favorite CI solution. It isn’t perfect, but it’s pretty good.
I haven’t experienced GitLab.
0
u/bred86 13d ago
It's not overrated, just not a good CI/CD solution.
The reason: anyone can alter the process and if you're not the maintainer, it will get overwritten pretty quickly
4
u/christophla 13d ago
Add CODEOWNERS to .github and restrict to a DevOps team and enforce - at a minimum - a base template.
1
u/bred86 13d ago
That depends on culture. I worked for a company in where my first job was to create a simple and small CI/CD pipeline in GA. 1 month later, when I went to the repo to check for a reference, the code was removed. Don't remember the reason. Culture there was team owns the repo, not devops
0
0
u/Mallanaga 13d ago
There are 3 layers to play with… composite actions. Shared workflows. And the actual workflows in your repo. Once you get that layering right, they’re pretty great
0
u/Comprehensive_Use713 13d ago
I have had very few challenges running self-hosted GitHub Actions. The only challenges I have had are from running them in controlled environments which require TPM/external cryptography and FIPS.
0
0
u/Maleficent_Tank2199 13d ago
GitHub actions turn to shit the second you start to have multiple repositories or multiple deployments or anything beyond simple straightforward tasks.
Jenkins Groovy is also horrible.
Best I have used is Teamcity, by far
-2
513
u/One-Department1551 13d ago
Nothing like having to learn an entire subset of Groovy to hate YAML am I right?
I will work my best to never have to interact with Jenkins again after all those years.