GitHub Actions - CI/CD That Actually Lives Inside GitHub

GitHub Actions launched in 2019 and basically killed the external CI/CD market overnight.

Why pay CircleCI like 130 bucks a month when GitHub gives you a few thousand free minutes? Why maintain a Jenkins cluster when you can just write YAML files that actually work?

Here's the deal: Git

Hub Actions runs your CI/CD stuff directly inside GitHub repositories.

Push code, trigger workflows, deploy to production

• all without leaving GitHub. It's not revolutionary, it's just convenient as hell.

The Reality Check

I've been debugging GitHub Actions since 2020, and here's what actually matters:

• Free tier is decent
• unlimited public repos, few thousand minutes for private ones
• YAML debugging will break your soul
• spent like 2 hours yesterday on a missing space
• **Windows costs double, mac

OS is fucking insane**

• Apple licensing means 10x pricing
• Marketplace actions are sketchy
• pin to commits or watch your deploys randomly explode
• Still better than babysitting Jenkins
• low bar but whatever

What Problems It Actually Solves

Look, I'm tired of maintaining CI servers.

GitHub Actions fixes that:

No more weekend Jenkins outages.

No more webhook bullshit between Git

Hub and CircleCI. Secrets live in your repo settings instead of some plugin that breaks every update. Open source gets unlimited builds. And uploading artifacts doesn't require configuring AWS buckets.

The Technical Reality

GitHub spins up fresh VMs for each job. Linux gets decent specs depending on whether your repo is private. Windows costs double the minutes. macOS costs 10x because Apple's licensing is ridiculous.

Jobs timeout after like 6 hours. If your build takes longer than that, you have bigger problems. The runner images get updated weekly with whatever tools are popular, so you don't maintain your own build agents like with Jenkins.

Honestly, it just works for most stuff. But here's what happens when you try to run it in production...

When to Use GitHub Actions vs Alternatives

Use GitHub Actions if:

• Your code's on GitHub anyway
• You're tired of paying CircleCI's bills
• Jenkins maintenance is killing your weekends
• You want matrix builds without the complexity
• You need dependency caching that actually works

Skip it if:

• You need complex pipeline orchestration (look at Tekton or Argo)
• Your builds need special hardware (self-hosted is possible but painful)
• You're deep in Git

Lab or Azure DevOps already

• GitHub's privacy terms don't work for your compliance
• You need advanced pipeline approvals beyond basic environments

Why This Matters

GitHub Actions didn't revolutionize CI/CD

• it just made it convenient. Instead of treating automation like separate infrastructure that needs babysitting, Actions makes it feel like part of your repo. You push code, stuff happens, you go back to building features.

The convenience has trade-offs. YAML will frustrate you. Marketplace actions will break at the worst times. Bills might surprise you if you're not careful with macOS builds. But for most teams, the productivity gains beat the headaches.

The real question isn't whether you should use GitHub Actions. It's how to use it without losing your sanity. Let's talk about what that actually looks like.

Been running GitHub Actions in production since 2020. Here's the stuff that matters when you're debugging at 3 AM.

The YAML Will Break You

YAML is great until you spend hours debugging a deployment failure because you used tabs instead of spaces. The error message? "Process completed with exit code 1." Super helpful, GitHub.

Pro tip: Don't trust VS Code's YAML validator. It doesn't catch runner-specific syntax errors and will let you push broken configs all day long.

Here's some YAML that looks fine but will ruin your day:

## This fails and you'll hate life
- name: Deploy
  run: |
    npm run build
     npm run deploy  # Extra space = "Error: Process completed with exit code 126"

Marketplace Actions: A Trust Fall

The GitHub Marketplace has thousands of actions. Most are abandoned. Some are broken. A few will randomly stop working Tuesday morning at 9 AM.

I trusted docker/build-push-action for ages - never had issues. Then one random Tuesday morning, all our deployments started shitting the bed. Turns out Docker changed their auth flow without warning and the action maintainer was MIA. Meanwhile our staging environment was completely fucked and the CTO kept asking for "status updates." We ended up reverting to raw Docker commands just to ship anything.

The problem isn't limited to third-party actions. Even official GitHub actions randomly break. actions/checkout@v4 broke Git LFS workflows for like weeks. actions/setup-node stopped detecting pnpm lockfiles randomly, turning 2-minute cached builds into 15-minute npm hell.

Always check the action's issues page before using it. High-quality ones like super-linter have active maintainers. Sketchy ones have abandoned GitHub repos with unanswered bug reports.

Cost Reality Check

GitHub's pricing looks generous until you hit Windows or macOS runners:

• Linux: reasonable
• Windows: 2x cost
• macOS: 10x cost (thanks Apple licensing)

Want to build iOS apps? Get ready for sticker shock. Team I was working with was spending maybe 60 bucks a month on React Native builds with CircleCI. Moved to GitHub Actions and the first bill was insane - like $900 or something crazy. Turns out they were running full iOS builds on every PR, including draft ones that devs push constantly while debugging. The free tier's macOS minutes lasted maybe 4 days.

Some teams switched to Xcode Cloud or Bitrise for iOS stuff to control costs.

Self-Hosted Runners: Great Until They're Not

Self-hosted runners sound appealing - use your own hardware, save money, full control. Reality: they randomly lose connection to GitHub, struggle with networking in Kubernetes, and need constant babysitting.

When self-hosted runners fail:

1. Check if the runner process died (it probably did) - look for "Runner listener exited with error code 2"
2. Verify network connectivity to api.github.com
3. Delete the runner and re-register it - classic IT crowd solution
4. Question your life choices

Most teams go back to GitHub-hosted runners after fighting infrastructure issues.

The 6-Hour Job Limit

Jobs timeout after like 6 hours. Seems generous until you're building a massive monorepo. When jobs hit the limit, they get killed mid-process, potentially leaving your deployment half-fucked. The timeout error just says "The job was canceled" with zero indication it was a timeout. I've seen teams debug "random cancellations" for days before realizing they hit the limit.

Secrets Management Gotchas

GitHub's secrets system is decent but has weird limitations:

• Secrets aren't available in forked repos (security feature, deployment nightmare)
• No automatic rotation
• Accidentally echoing secrets in logs gets them redacted as ***
• Environment secrets require manual approval workflows

Some teams integrate Azure Key Vault or AWS Secrets Manager for better rotation, but it adds complexity.

Resource Limits That Bite

Each runner gets limited disk space. Sounds like plenty until you're building Docker images with large base images or caching node_modules. Jobs fail with "No space left on device" and you're wondering why GitHub allocated such tiny disks. I've seen Docker builds fail because the runner had like 2GB of temp space remaining but Docker needed 3GB for intermediate layers.

CircleCI gives you more space. Azure DevOps agents have less but with better cleanup. Consider disk cleanup scripts or external storage if you're tired of builds failing because GitHub can't allocate a reasonable amount of disk space.

Error Messages That Lie

Most common error: "Process completed with exit code 1." This tells you absolutely nothing useful. You'll spend more time reading logs than writing code.

GitHub's UI makes finding the actual problem an archaeological expedition through collapsed log sections. CircleCI's error highlighting is way better.

Pro tip: Use enhanced logging with ACTIONS_STEP_DEBUG for more detailed output. Tools like act let you debug workflows locally. The GitHub CLI helps with log analysis from command line.

The Reality Check

This isn't meant to scare you away - it's meant to prepare you. Every CI/CD tool has gotchas. GitHub Actions' gotchas are manageable if you know they exist.

Teams that struggle expect it to "just work" without understanding the complexity. Teams that succeed plan for YAML debugging sessions, budget for macOS builds properly, and have strategies for when third-party actions break.

From Jenkins to GitHub Actions: 3 Months of Hell

Migrating from Jenkins isn't just converting Groovy to YAML. Found this out the hard way when I volunteered to move our Jenkins setup to GitHub Actions.

Started with the "simple" jobs. Everything looked perfect in testing. Felt like a genius for maybe a week.

Then discovered our Ansible deployment scripts had Jenkins URLs hardcoded everywhere. Spent like a week doing find-and-replace across the entire codebase.

Took me forever to realize GitHub Actions has no equivalent to Jenkins' build trigger system for downstream jobs. Tried workflow dispatch events but they're completely different. Had to redesign the entire deployment pipeline.

Lead architect came back from vacation: "where the fuck is the database migration job?" Turns out it was buried in some Jenkins shared library nobody documented. Spent days reverse-engineering Groovy code nobody understood.

Finally got everything working, then discovered GitHub Actions doesn't keep runners warm between jobs like Jenkins agents do. Our 8-minute builds became 12-minute cold-start nightmares.

Eventually gave up on perfect feature parity and shipped a "good enough" version. Team was pissed about the performance regression for months, but at least we weren't maintaining Jenkins on weekends anymore.

From CircleCI: The Billing Surprise

CircleCI was costing us maybe $150 or something for our team. GitHub Actions looked basically free with our existing plan. First month's bill: like $400 something.

Turns out CircleCI included macOS builds in their pricing. GitHub Actions charges 10x for macOS minutes, and our React Native iOS builds were running on every PR because nobody configured branch protection right.

Some teams switched to Xcode Cloud or Bitrise for iOS builds to control costs.

The Docker Registry Integration Hell

Jenkins worked fine with our private Docker registry. GitHub Actions required:

1. Setting up separate authentication with docker/login-action
2. Configuring registry secrets for each repo
3. Debugging why pulls worked but pushes failed (permission issues)
4. Discovering GitHub Packages exists but costs extra

AWS ECR and Google Artifact Registry have better GitHub Actions integration than generic private registries.

Self-Hosted Runner Reality

Thought self-hosted runners would solve our cost problems. Set up maybe 5 dedicated machines in AWS. Within a month it was a complete shitshow:

• Couple runners just randomly disconnected and never came back
• Kubernetes networking broke runner communication like twice
• Security updates meant taking runners offline constantly
• Debugging runner issues took way more time than the money we saved

Switched back to GitHub-hosted runners and accepted the costs. Enterprise teams with dedicated infrastructure have better luck.

The Artifact Storage Trap

GitHub Actions artifacts looked great for passing build outputs between jobs. Didn't realize GitHub charges for storage. Our monthly bill jumped like $180 or something because we were uploading test reports for every build and GitHub stores that shit for 90 days by default.

Nobody told us about automatic cleanup until we got sticker shock from billing.

Consider external storage like S3 for long-term artifacts. Teams also use pruning actions to clean up old builds and implement compression to reduce costs.

These lessons were learned the hard way. But what about day-to-day problems once you're running in production? Here are the questions that come up constantly.