GitHub Actions

GitHub Actions has no lockfile system to pin exact versions of third-party actions. Every workflow run re-resolves dependencies from the manifest without recording what was actually chosen, creating non-deterministic builds and enabling supply chain attacks. This is a fundamental gap compared to mature package managers.

The GitHub Actions log viewer is unreliable and crashes browsers when viewing long build logs or searching through them. Developers report that Chrome crashes repeatedly when trying to debug failed builds, making it the only major CI system with this critical usability issue.

GitHub applies breaking changes to Actions with insufficient notice (e.g., self-hosted runner version rejections). When production deployments depend on Actions, forced updates can require hours of investigation and testing to fix stable workflows, with no option to skip upgrades.

99.8% of GitHub Actions workflows are over-privileged, meaning repositories grant excessive permissions that increase vulnerability to attacks. Secrets are scoped at repository or organization level, flowing broadly by default in reusable workflows without fine-grained controls to bind credentials to specific execution contexts.

GitHub Actions requires explicitly naming required status checks, but in monorepos with dynamic pipelines, only relevant checks should be mandatory. If a PR only touches `api1` but `web-app1` checks aren't triggered, the PR cannot merge even though all relevant checks passed. This forces developers to run unnecessary pipelines just to satisfy merge requirements.

Security Vulnerability is the most prevalent issue reported in the GitHub Actions ecosystem according to empirical analysis of GitHub Discussions and Stack Overflow. The Marketplace contains actions of varying quality and security posture, posing risks to users who rely on community-maintained code.

GitHub does not release Docker containers matching the public runner images. Self-hosted runners have poor support for rootless Docker-in-Docker and other standard configurations. GitHub expects users to do 90% of the work to maintain self-hosted infrastructure, yet charges for the service.

The security architecture contains too many edge cases and inconsistencies (e.g., not recommending self-hosted runners in public repos). This expanded attack surface makes it easy to introduce vulnerabilities inadvertently while setting up workflows.

GitHub Actions encourages poor practices because common tasks (e.g., sending Slack messages) have convoluted official solutions. Developers end up hand-rolling scripts, creating an undocumented black box system that becomes unmaintainable at scale without external tooling like NX.

GitHub Actions suffers from recurring control plane problems including broker/backend message relay failures, hung logs, unexplained outages, and unsafe default behaviors (e.g., safe_sleep). These are long-standing issues that undermine trust in CI/CD reliability.

GitHub suddenly introduced additional per-minute charges for GitHub Actions minutes in December, breaking established budgets across enterprise teams. No per-second billing option exists, and the announcement left no time for departments to adjust fiscal budgets, creating surprise costs mid-fiscal-year.

Debugging failed builds in GitHub Actions requires multiple page loads and clicks, each with significant loading spinners. Navigation is unreliable—the back button behaves unpredictably, forcing developers to memorize URLs or search browser history. The entire debugging experience is described as navigating bureaucratic forms.

Debugging issues in GitHub Actions is time-consuming because there is no single comprehensive troubleshooting guide. Developers face delays when errors occur, and the slow feedback loop compounds the difficulty. Documentation is insufficient for complex scenarios.

Forgejo and Codeberg maintain GitHub Actions compatibility for user migration, but this locks them into reproducing the same broken architecture (missing lockfiles, no registry, poor security model). The fundamental design flaws are baked into the compatibility layer and cannot be fixed without breaking compatibility.

The previous 10GB cache limit forced teams with large dependencies or multi-language monorepos to have build dependencies evicted before the next workflow run, requiring repeated downloads and slowing builds. While recently increased, this was a long-standing pain point.

GitHub Actions are stateless, making it difficult to reuse computation within VMs without relying on external tools like Make or Just. Even with caching layers, developers cannot reliably persist state between runs, forcing redundant rebuilds and slowing feedback loops.

As pipelines grow, developers must add numerous `if` statements to handle different triggers (push, manual, etc.). Reusing workflows requires boilerplate duplication and managing 30+ YAML files. This creates maintenance burden and makes it difficult to refactor without breaking `needs` clauses.

Workflow syntax errors and broken `needs` clauses are only discovered after pushing code. Linters exist but are imperfect. Developers cannot validate workflows locally before commit, forcing a push-and-wait debugging cycle.

GitHub Actions feels overwhelming for new users due to the range of features, options, and complexity of setting up workflows. The platform's learning curve is especially steep for those new to version control or CI/CD concepts.

Free GitHub-hosted runners perform 4-5x slower than comparable local hardware (e.g., i7-13700H mini-PC). This forces teams running Jenkins locally to accept longer build times (30 min to 40 min) even after parallelization, impacting developer velocity.

GitHub Actions provides no simple way to re-run workflows against the tip of a branch, making it difficult to handle transient failures and test workflow changes. Developers must work around this limitation by adding additional triggers, which is unintuitive and slows development velocity.

GitHub Actions workflows generated between 150.5 and 994.9 million tons of CO₂ equivalent in 2024, creating a significant environmental concern for companies mindful of their carbon footprint.

Users struggle to find suitable actions in the GitHub Actions Marketplace and evaluate their quality. A survey revealed that 7 out of 25 participants found it difficult to navigate and select appropriate actions, leading some teams to maintain their own local actions instead.