GitHub Actions is slowly killing engineering teams

Infrastructure & IaC Side Thread (CloudFormation/CDK/Terraform)

• Several comments parallel the author’s pain with GitHub Actions to CloudFormation/CDK: slow, fragile, awkward failure modes, and “dependency deadlocks” when stacks share exports.
• Others push back, arguing CDK mitigates some antipatterns (e.g., forcing generated names) and that many issues come from design/usage rather than the tool itself.
• Terraform/Ansible are mentioned as preferred by some, but often blocked by organizational standardization on CloudFormation.

Perceived Problems with GitHub Actions

• UX: Log viewer often crashes browsers or mangles ANSI-colored output, making frequent log reading painful. Workarounds like downloading logs and using less -R are seen as too high-friction.
• Reliability: Reports of flaky actions/checkout, missed or duplicated triggers, unreliable cron, and overall declining stability.
• Complexity: YAML-as-DSL plus conditionals and marketplace “actions as plugins” encourages hidden logic, hard-to-debug pipelines, and trial‑and‑error loops.
• Tying CI to the code host is seen as lock‑in; some prefer webhooks to external CI.
• Enterprise Server users cite missing features and quirks (label triggers, lack of persistent state, GHES lagging github.com).

Defenses of GitHub Actions / “Good Enough” View

• Many find Actions perfectly fine or even a “godsend,” especially for OSS and small teams: low friction, integrated with GitHub, removes need to run build infrastructure.
• Several argue CI should mostly “run a script” and stay thin; if most logic lives in Makefiles/bash/build tools, migration between CI systems is manageable.
• Some call the “killing teams” framing hyperbolic; issues are often process or culture (no local dev parity, overcomplex pipelines) rather than GHA itself.

Buildkite and Other CI Systems

• Buildkite gets strong praise for dynamic pipelines, owning your own compute, solid logging, and simple agent model. Some consider it the gold standard; others see its dynamic-pipeline story as pushing complexity into ad‑hoc scripts and re‑implementing basics.
• Other tools mentioned: GitLab CI (generally liked), Jenkins (unpopular but powerful when well‑run), TeamCity, Drone/Woodpecker, RWX, Vela, Bitbucket Pipelines, Azure DevOps. Opinions vary widely; no system is viewed as universally good.

YAML, DSLs, and Workflow Philosophy

• Broad frustration with “programming in configuration” and bespoke CI DSLs.
• Some advocate declarative configs plus real languages for logic; others emphasize a single canonical local build (Make, just, etc.) mirrored in CI.
• Persistent theme: lack of easy local reproduction of CI remains a major pain point.

Security & Marketplace Concerns

• Using third‑party actions (uses: author/action@version) for core tasks feels risky; pinning SHAs or forking still doesn’t lock transitive dependencies.
• Comparison is made to proper package managers with lockfiles; Actions’ model is seen as immature for supply‑chain security–sensitive orgs.

Role of AI/LLMs

• Some say LLMs drastically reduce the pain of understanding bash/Actions YAML and porting pipelines (e.g., GitLab → GHA).
• Others warn this risks normalizing overly complex, poorly designed systems by papering over them with AI assistance.

Meta: Tone, Branding, and Hyperbole

• A few suspect the post is effectively an ad for Buildkite or even LLM‑written based on tone; Buildkite staff in the thread deny any coordination.
• Buildkite’s experimental “CLI-style” homepage draws criticism as confusing, though acknowledged as an experiment being retired.
• Many agree with specific criticisms while rejecting the life‑or‑death rhetoric; CI is annoying and important, but tools like Actions are, for a large class of teams, “annoying yet adequate.”