Module 1: Why Cicd And Gitops
5. GitHub Actions and its alternatives, with market honesty
Description
You already know what CI/CD is and what GitOps is, in principle. This lesson answers the question left pending: of all the tools that implement that principle, why does this guide choose GitHub Actions? The answer isn't "because it's the best" in the abstract, nor "because it's the most-used" — the market evidence motivating this guide is, in fact, more uncomfortable than that. You're going to meet GitLab CI, CircleCI, and Jenkins with the exact evidence of where each one dominates, and you're going to understand why this guide chooses GitHub Actions as a pedagogical vehicle, without pretending it "wins" everywhere.
Connection to the module
This is the module's last purely conceptual lesson. Lessons 6 and 7 are hands-on: you install exactly the tool this lesson justifies, and you run your first workflow with it. Everything you learn from here through Module 8 is GitHub Actions specifically — but the vocabulary you built (CI, CD, GitOps) is the same, no matter which of these tools you end up using in a real job, and Module 7 (lesson 2) returns to this contrast in more depth, showing that the pattern transfers even though the syntax changes.
The market evidence, unsoftened
The market audit motivating this entire guide (src/paths/aws-cloud-ecosystem/VALIDACION.md, July 2026) is specific about which tool dominates where, and it corrects an easy intuition — the assumption that "GitHub Actions is what everyone uses today." The full quote, unedited:
"CookUnity 'GitHub and GitHub Actions'; EarnIn 'GitHub Actions, Argo CD'; against the real Spanish-market stack: IRIUM 'Git, Jenkins, Artifactory, SonarQube', Apptiva 'Jenkins administration expertise', MediaStream 'Jenkins, TeamCity' — Jenkins appears in 5 of 13, almost double GitHub Actions (~3)."
Read it twice. The most-cited direct evidence —the CookUnity and EarnIn postings, companies with real presence in the Spanish-speaking tech market— names GitHub Actions explicitly. But when the complete universe of 13 surveyed postings is counted, Jenkins appears almost twice as often. It's not a close tie: it's a clear signal that, in the real Spanish-language stack, Jenkins remains the CI/CD tool most companies take for granted — often alongside tools from the same veteran ecosystem, like Artifactory (artifact management) and SonarQube (static code quality).
This guide doesn't hide that evidence to justify its choice. It names it, in full, in this lesson, and chooses GitHub Actions for reasons different from "it's what's asked for the most" — reasons you're going to read below.
The four tools, by contrast
| GitHub Actions (this guide) | GitLab CI | CircleCI | Jenkins | |
|---|---|---|---|---|
| Who maintains it | GitHub (Microsoft) | GitLab Inc. | CircleCI Inc. | Open source community, governed by the Continuous Delivery Foundation |
| Where the config lives | .github/workflows/*.yml, in the same repo | .gitlab-ci.yml, in the same repo | .circleci/config.yml, in the same repo | Jenkinsfile (pipeline as code) or configuration via a web interface — both coexist in practice |
| Hosting model | SaaS integrated with GitHub; hosted or self-hosted runners | SaaS integrated with GitLab; hosted or self-hosted runners | Independent SaaS, connects to any Git provider | Almost always self-hosted — its own server, requires maintenance |
| Integration marketplace | Enormous — thousands of reusable third-party Actions | Smaller, with its own templates | Orbs (reusable packages), a narrower ecosystem | Plugins — the oldest and largest ecosystem, but with uneven maintenance across plugins |
| Market signal (Spanish stack, 13 postings) | ~3 of 13 | Named, a minority in the sample | Doesn't appear in the cited sample | 5 of 13 |
None of the four is "worse" in any absolute sense — they're real tools, in production, at real companies. Each one solves the same problem with different design decisions.
Jenkins is the most veteran of the four tools (born in 2011, as a fork of Hudson) and its dominant presence in the Spanish stack probably reflects exactly that: companies with CI/CD infrastructure established years ago, that already invested in their own Jenkins server, in configured plugins, in people who know how to operate it. Migrating off Jenkins has a real cost, and "because we already have it" is a legitimate business reason to keep using it.
GitLab CI competes directly with GitHub Actions on the same model —configuration in the repository itself, with no separate server to maintain— and is the natural choice for teams already using GitLab as their version control platform.
CircleCI was, for years, one of the most widely adopted SaaS CI platforms before GitHub Actions and GitLab CI matured their own integrated offerings; it remains a real option, especially for teams using a Git provider other than GitHub or GitLab.
Why this guide chooses GitHub Actions (without pretending it "wins")
This guide's choice has three concrete reasons, none of which is "it dominates the market":
1. Zero friction to learn. GitHub Actions doesn't require installing or maintaining a separate server (unlike Jenkins, which almost always lives self-hosted). The configuration lives in the same repository as the code it describes, in YAML, with no additional web interface to learn to navigate.
2. act exists. This is, in practice, the decisive reason: act executes the same YAML that would run on github.com, for free, in Docker, on your machine — without needing a GitHub account or spending a single minute of hosted runners. None of the other three tools in this lesson has such a direct, mature, and widely adopted equivalent for running their pipelines entirely locally. It's the piece that makes this entire guide's $0, reproducible commitment possible — you're going to install it in lesson 6.
3. It's the tool named in the direct evidence. Even though Jenkins dominates in frequency within the surveyed Spanish stack, the two most textually cited postings in the audit —CookUnity and EarnIn— name GitHub Actions explicitly. It's not the most frequent signal, but it's a real, verifiable one.
What this guide does NOT claim: that GitHub Actions is "better" than Jenkins, that you're going to find it more often than Jenkins in a Spanish-language job posting, or that learning GitHub Actions exempts you from having to learn Jenkins someday if your next job already uses it. The evidence says the opposite in frequency (5 of 13 versus ~3 of 13). What is true, and is this guide's pedagogical bet: the pattern you're going to learn —plan on every change, review before merging, apply triggered by the merge, secrets managed by the platform, environments with approval— is the same pattern you'd implement in Jenkins, with Jenkinsfile syntax instead of Actions YAML, or in GitLab CI, with .gitlab-ci.yml instead of .github/workflows/. Module 7 (lesson 2) shows you that syntax contrast in more detail, precisely so the knowledge transfers, instead of staying tied to a single tool.
Common mistakes
Concluding that "GitHub Actions won" because this guide chose it (the most important one in this lesson). What happens: someone reads this guide's choice as a claim that GitHub Actions is, in market terms, the dominant tool. Why it happens: it's natural to assume that the tool a course teaches is "the best" or "the most in-demand." How to spot it: if your summary of this lesson is "GitHub Actions is what's used today" instead of "Jenkins dominates the surveyed Spanish stack, 5 of 13 against ~3 of 13, and this guide chooses GitHub Actions for other reasons." How to fix it: reread the complete VALIDACION quote at the start of this lesson. Market honesty is, on purpose, part of the content — not a marginal detail.
Thinking learning GitHub Actions is "a waste of time" because Jenkins dominates the Spanish stack (overcorrection of the previous mistake). What happens: someone, after reading the Jenkins evidence, concludes they should skip this guide and learn Jenkins directly. Why it happens: it's a reasonable reaction to the evidence, but it ignores the real reason for the pedagogical choice —zero friction to learn, and above all, act. How to spot it: if you think this guide's knowledge "doesn't transfer" to a job that uses Jenkins. How to fix it: the pattern (plan-review-apply, managed secrets, environments with approval) is the same across any of the four tools in this lesson — the syntax changes, not the design. Learning the pattern with the lowest-friction tool to practice with (GitHub Actions + act) is a valid learning strategy, not a blind bet that "this specific tool is what you're always going to use."
Assuming Jenkins is "outdated" for being the most veteran tool (conceptual). What happens: someone, seeing that Jenkins was born in 2011 (as a fork of Hudson, an even older project), concludes it's obsolete technology companies are moving away from. Why it happens: it's intuitive to associate "older" with "declining." How to spot it: if your conclusion from this lesson is that Jenkins "isn't used anymore" or "is dying." How to fix it: this very lesson's evidence says exactly the opposite — Jenkins appears in 5 of 13 postings in the surveyed Spanish stack, more than any other tool in this comparison. Being veteran and actively in production at real companies aren't contradictory things; in fact, it's common for the oldest CI/CD infrastructure to also be the most entrenched and hardest to replace in large organizations.
Exercises
Exercise 1 — Recite the exact quote. Without looking at this lesson, write from memory the two exact numbers from the market evidence (Jenkins vs. GitHub Actions, out of how many total postings) and name at least two of the three Spanish-stack companies cited with Jenkins.
See solution
Jenkins appears in 5 of 13 postings, versus ~3 of 13 for GitHub Actions. The three Spanish-stack companies cited with Jenkins are IRIUM ("Git, Jenkins, Artifactory, SonarQube"), Apptiva ("Jenkins administration expertise"), and MediaStream ("Jenkins, TeamCity"). If you remembered the exact numbers and at least two of the three companies, you have a clear grasp of the evidence underlying this lesson — not a vague impression of "Jenkins is popular," but the concrete data.
Exercise 2 — Defend this guide's choice to an informed skeptic. A colleague, who knows this lesson's evidence well, tells you: "if Jenkins dominates the real market, why does this guide waste time teaching GitHub Actions?" Answer them in three or four sentences, using this lesson's three concrete reasons (not an unsupported opinion).
See solution
A complete answer sounds, roughly, like this: "It's not that we ignore the evidence — Jenkins dominates the surveyed Spanish stack, and this guide says so explicitly. Choosing GitHub Actions is pedagogical, not a bet that 'this is what you're always going to use': it has zero friction to learn (no separate server to install or maintain), and above all, act exists, a tool that runs the same YAML for free and locally, with no GitHub account — that's what makes it possible for this entire guide to cost $0 and be reproducible on any machine. The pattern you learn —plan before merging, automatic apply afterward, managed secrets, environments with approval— is the same one you'd use in a Jenkinsfile, just with different syntax; Module 7 shows you that contrast directly."
Exercise 3 — Sort each tool by its hosting model. Without looking at this lesson's table, classify the four tools (GitHub Actions, GitLab CI, CircleCI, Jenkins) according to whether they typically require the company itself to maintain a server, or whether they live as SaaS integrated with the Git provider.
See solution
SaaS integrated with the Git provider (no own server to maintain by default): GitHub Actions (integrated with GitHub) and GitLab CI (integrated with GitLab) — both offer hosted runners by default, though they also allow self-hosted runners as an option. SaaS independent of the Git provider: CircleCI — it connects to GitHub, GitLab, or Bitbucket, but is a separate service. Almost always requires its own server: Jenkins — it's the only one of the four that, in the vast majority of real cases, runs on infrastructure the company itself installs and maintains, which partly explains why migrating away from Jenkins carries a real inertia cost for companies that already have it running.
Summary and next step
In this lesson you learned the complete, unedited market evidence: Jenkins appears in 5 of 13 postings in the Spanish stack surveyed by this ecosystem's audit, almost double GitHub Actions (~3 of 13) — even though the two most textually cited postings (CookUnity, EarnIn) do name GitHub Actions. You met GitLab CI and CircleCI by contrast, and understood the three concrete reasons this guide chooses GitHub Actions: zero friction to learn, the existence of act (the piece that makes the $0 commitment possible), and being the tool from the direct evidence — without any of those three reasons meaning GitHub Actions "wins" in the general market.
Before moving on you should be able to: cite the exact Jenkins vs. GitHub Actions figure in the Spanish stack; name the four tools in this lesson and something distinctive about each one; and explain, without saying "it's the best," why this guide specifically chose GitHub Actions.
This closes out all the module's theory. Lesson 6 turns everything you've learned —the real problem, the CI/CD vocabulary, GitOps, the honest tool choice— into this guide's first executed command: you're going to install act.
Resources
- GitHub Docs — GitHub Actions — official documentation for the tool you install in lesson 6.
- GitLab Docs — CI/CD — official documentation for GitLab CI, the alternative named in this lesson.
- CircleCI Docs — official CircleCI documentation.
- Jenkins — Documentation — official Jenkins documentation, the tool with the largest presence in the Spanish stack according to this lesson's evidence.
src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA, market audit, Jul-2026) — the exact source of the Jenkins vs. GitHub Actions quote used in this lesson.