--- title: GitHub Actions could be so much better | daily.dev description: A detailed critique of GitHub Actions from a long-time daily user, covering four major pain points: the slow and frustrating debugging cycle (requiring... canonical: https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: GitHub Actions could be so much better | daily.dev og:description: A detailed critique of GitHub Actions from a long-time daily user, covering four major pain points: the slow and frustrating debugging cycle (requiring... og:url: https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9 og:image: https://api.daily.dev/og/posts/MSBy5Vun9.png og:image:alt: GitHub Actions could be so much better og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # GitHub Actions could be so much better **[Lobsters](https://daily.dev/sources/lobsters)** · 13 min read · 1 upvotes · 2 comments ## Summary A detailed critique of GitHub Actions from a long-time daily user, covering four major pain points: the slow and frustrating debugging cycle (requiring multiple git push cycles for trivial fixes), serious security footguns (expression injection via `${{ }}`, dangerous `pull_request_target` event, over-scoped tokens, and imposter SHA commits on forks), inconsistent and limited type system for action inputs, and GitHub's neglect of official first-party actions. The author proposes concrete improvements including interactive debugging, push-time workflow validation, a paranoid security mode, deprecation of `pull_request_target`, expanded type support, and more officially maintained actions or a pseudo-official community org. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why is using a SHA-pinned reference to actions/checkout still potentially insecure? A SHA can appear to belong to a trusted repository like actions/checkout while actually being a commit that only exists on a fork within that repository's network. GitHub's commit-lookup API returns a response naming the upstream repo even when the referenced SHA only lives on a fork, so a pinned SHA that looks legitimate can actually run attacker-controlled code from a fork. _Developers hardening CI pipelines can track supply-chain gotchas like this one on daily.dev._ ### Why is the pull_request_target event in GitHub Actions considered dangerous? It runs with the permissions and secrets of the base repository while still being triggerable by a pull request from an untrusted fork, making it practically impossible to use safely in any non-trivial workflow. It was intended for narrow uses like labeling or commenting on fork PRs, but GitHub's own Security Lab has flagged it as risky for years, and some argue it should be deprecated entirely. _Teams choosing safer CI/CD patterns can follow ongoing GitHub Actions security discussion on daily.dev._ ### What official GitHub Actions used to exist but were deprecated in favor of third-party replacements? actions/create-release was deprecated in favor of softprops/action-gh-release, actions/upload-release-asset was also folded into that transition, and actions/setup-ruby was deprecated in favor of ruby/setup-ruby. The stated reason for these deprecations was maintainer time, revealing that these widely used official actions had effectively been side projects. _Maintainers migrating off deprecated GitHub Actions can track ecosystem shifts like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 508 comments across lobsters, hackernews (as of 2026-09-14). **TL;DR:** Commenters broadly agree with the post's critique — especially the painful push-debug-commit loop and YAML-as-a-programming-language problem — but the most upvoted practical advice is to treat GitHub Actions as a thin wrapper around real scripts rather than waiting for GitHub to fix things. Security concerns get less airtime than the DX frustrations. **Sentiment:** 15% positive · 55% mixed · 30% skeptical **The case for** - Keeping workflows thin (50–60 lines) by delegating logic to shell/make scripts dramatically reduces the debug loop pain and vendor lock-in. - Tools like `act` (nektos) can handle ~90% of local iteration and save teams from dozens of throwaway test commits. - Using GitHub Actions purely as a task substrate (triggering `make` targets) makes pipelines portable across CI systems and runnable locally. **The pushback** - The YAML DSL is too weak to stand alone yet too entrenched to replace, forcing developers into an embedded shell-script hybrid that is hard to test or type-check. - The commit-push-wait debug cycle feels like a regression to punch-card-era development, with no first-party interactive debugging. - Compared to GitLab CI, GitHub Actions still feels like a toy — it largely copied features rather than innovating, and the runner itself is a fork of Azure Pipelines with its own portability baggage. - Third-party actions in the marketplace create deep vendor lock-in and complexity traps that teams repeatedly fall into despite knowing better. - GitHub's homepage enshittification (social feed, Copilot CTAs) signals a broader neglect of developer-focused UX that extends to Actions. **By community** - hackernews (mixed): Heavily engaged thread that validates the critique but pivots quickly to a pragmatic workaround — keep YAML thin and push logic into scripts — with significant debate about whether that's always feasible. - lobsters (skeptical): Commenters are more structurally critical, questioning whether YAML-based CI can ever be adequate and surfacing the Azure Pipelines lineage as an explanation for Actions' architectural shortcomings, while also venting about GitHub's broader enshittification. **Hottest debate:** Whether treating GitHub Actions as a pure script-runner (option 2) is a realistic universal solution or just a workaround that breaks down for artifact management, multi-runner pipelines, and GitHub-specific automation. **Open questions** - Why hasn't GitHub adopted or officially integrated `act` for local workflow execution? - Could a typed, compiled language (Elm-like or TypeScript-based) replace YAML as the workflow definition layer without sacrificing declarative simplicity? - Is there a clean way to share build scripts across multiple repositories without resorting to git submodules or publishing them as actions? **Highlights** > There are two types of github actions workflows you can build. 1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in. 2) Configure with github actions. Always ask yourself "can I push this YAML complexity into a script?" and do it if you can. Send an email? Yes, that can go in a script. Your workflow ends up being about 50-60 lines as a result and very rarely needs to be changed once you've set up. Github actions is suddenly fine and you rarely have to do that stupid push-debug-commit loop because you can debug the script locally. Every time I join a new team I tell them that 1 is the way to madness and 2 is the sensible approach and they always tepidly agree with me and yet about half of the time they still do 1. The thing is, the lack of debugging tools provided by Microsoft is also really not much of a problem if you do 2, vendor lock in is lower if you do 2, debugging is easier if you do 2 but still nobody does 2. > — [MoreQARespect on hackernews · 25 comments](https://news.ycombinator.com/item?id=37613520) > These half-assed programming languages in yaml are tremendously frustrating, I keep wondering how much better and simpler things would be if instead of that it were an actual programming language, with a declarative bend. The thing is too weak to be fully useful on its own and has to embed shell scripts *anyway*, at that point why not have an Elm-like language except instead of creating the integration of an event stream into a web application it simply maps an Event into a Job, and the entire thing is completely typed, and you can have a "standard library" of utilities which you can actually look up, and you can define your own common utilities and variables? And you can run the compiler locally so you at least know what you wrote is not *complete* nonsense, even if your shell scripts may be broken. > — [masklinn on lobsters · 20 points, 5 comments](https://lobste.rs/s/veoan6/github_actions_could_be_so_much_better#c_j5byj9) > Honestly I still don't understand how GitHub managed to build something like GitHub Actions after seeing what GitLab-CI does. It's not perfect by no means, and it will never be, but the non-trivialities of such Ci system are almost infinite and building something secure, performant and widely usable requires some pretty involved thought process - little of which went into GitHub actions. > — [pl on lobsters · 6 points, 1 comments](https://lobste.rs/s/veoan6/github_actions_could_be_so_much_better#c_ghh0vk) > Option 2 also makes it easier for developers to run their builds locally, so you're essentially using the same build chain for local debugging than you do for your Test/Staging/Prod environments, instead of maintaining two different build processes. It's not just true for GHA, but for any build server really: The build server should be a script runner that adds history, artifact management, and permissions/auditing, but should delegate the actual build process to the repository it's building. > — [MenhirMike on hackernews · 1 comments](https://news.ycombinator.com/item?id=37614254) > I want to mention [act](https://github.com/nektos/act), a terribly-named tool for running GH Actions locally prior to push. It does not always work, but sometimes it can save time when debugging Actions. > — [Corbin on lobsters · 12 points, 1 comments](https://lobste.rs/s/veoan6/github_actions_could_be_so_much_better#c_nujug2) **Source threads** - [lobsters](https://lobste.rs/s/veoan6/github_actions_could_be_so_much_better) · 39 points · 48 comments - [hackernews](https://news.ycombinator.com/item?id=37612420) · 412 points · 460 comments ## Community discussion Top comments from developers on daily.dev. **@dcorto** · 0 upvotes > yeah could be... 🖖🖖🖖 **@agustinbarrientos** · 0 upvotes > For me, broken workflows should fail at push time before YAML turns into a four-commit debugging session. ## Similar posts on daily.dev - [GitHub Actions is the weakest link](https://daily.dev/posts/github-actions-is-the-weakest-link-kx8cbboab) · Andrew Nesbitt · 1 upvotes · 0 comments - [Hardening GitHub Actions workflows](https://daily.dev/posts/hardening-github-actions-workflows-husyvy6uw) · PHPUnit Expert · 0 upvotes · 0 comments - [A deep dive into GitHub Actions](https://daily.dev/posts/a-deep-dive-into-github-actions-az4oxlp76) · Flavio Copes · 2 upvotes · 0 comments - [Is GitHub Actions Putting Your Software at Risk?](https://daily.dev/posts/is-github-actions-putting-your-software-at-risk--a2b2a1jji) · Atomic Spin · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#devops](https://daily.dev/tags/devops), [#cicd](https://daily.dev/tags/cicd), [#github-actions](https://daily.dev/tags/github-actions) [View this post on daily.dev](https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"GitHub Actions could be so much better","url":"https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9"},"datePublished":"2026-08-11T02:28:04.368Z","dateModified":"2026-09-14T08:35:54.183Z","description":"A detailed critique of GitHub Actions from a long-time daily user, covering four major pain points: the slow and frustrating debugging cycle (requiring...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d5a7b8206de9ee80a0c0c030b12d79cb?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d5a7b8206de9ee80a0c0c030b12d79cb?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":2,"discussionUrl":"https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"keywords":"security,devops,cicd,github-actions","timeRequired":"PT13M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"GitHub Actions could be so much better"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9","comment":[{"@type":"Comment","text":"yeah could be… 🖖🖖🖖","datePublished":"2026-08-11T12:31:11.665Z","url":"https://daily.dev/posts/MSBy5Vun9#c-jqR0JPjmi","author":{"@type":"Person","name":"David C.","url":"https://daily.dev/dcorto","image":"https://media.daily.dev/image/upload/s--EPnTZZFw--/f_auto/v1784418453/avatars/avatar_tT4BuvxaHeTxyE5fH41si?_a=BAMAMicg0"}},{"@type":"Comment","text":"For me, broken workflows should fail at push time before YAML turns into a four-commit debugging session.","datePublished":"2026-08-12T02:49:55.379Z","url":"https://daily.dev/posts/MSBy5Vun9#c-N3nqruxZb","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/github-actions-could-be-so-much-better-msby5vun9#faq","mainEntity":[{"@type":"Question","name":"Why is using a SHA-pinned reference to actions/checkout still potentially insecure?","acceptedAnswer":{"@type":"Answer","text":"A SHA can appear to belong to a trusted repository like actions/checkout while actually being a commit that only exists on a fork within that repository's network. GitHub's commit-lookup API returns a response naming the upstream repo even when the referenced SHA only lives on a fork, so a pinned SHA that looks legitimate can actually run attacker-controlled code from a fork. Developers hardening CI pipelines can track supply-chain gotchas like this one on daily.dev."}},{"@type":"Question","name":"Why is the pull_request_target event in GitHub Actions considered dangerous?","acceptedAnswer":{"@type":"Answer","text":"It runs with the permissions and secrets of the base repository while still being triggerable by a pull request from an untrusted fork, making it practically impossible to use safely in any non-trivial workflow. It was intended for narrow uses like labeling or commenting on fork PRs, but GitHub's own Security Lab has flagged it as risky for years, and some argue it should be deprecated entirely. Teams choosing safer CI/CD patterns can follow ongoing GitHub Actions security discussion on daily.dev."}},{"@type":"Question","name":"What official GitHub Actions used to exist but were deprecated in favor of third-party replacements?","acceptedAnswer":{"@type":"Answer","text":"actions/create-release was deprecated in favor of softprops/action-gh-release, actions/upload-release-asset was also folded into that transition, and actions/setup-ruby was deprecated in favor of ruby/setup-ruby. The stated reason for these deprecations was maintainer time, revealing that these widely used official actions had effectively been side projects. Maintainers migrating off deprecated GitHub Actions can track ecosystem shifts like this on daily.dev."}}]} ```