I'll think twice before using GitHub Actions again

1. act

   1 183 70,766 7.2 Go

   Run your GitHub Actions locally 🚀

   

   Not sure if I am missing something but you can definitely run (some?) GH actions locally with act: https://github.com/nektos/act

   Seen a couple posts on here say otherwise.

2. SaaSHub

   www.saashub.com featured

   SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

   

3. meta

   2 5 2,208 0.0 JavaScript

   tool for turning many repos into a meta repo. why choose many repos or a monolithic repo, when you can have both with a meta repo?

   

   Guessing it's https://github.com/mateodelnorte/meta googlefu "meta github repo"

4. NATS

   3 136 19,998 9.9 Go

   High-Performance server for NATS.io, the cloud and edge native messaging system.

   

   hey thanks!

   definitely interesting!

   I do wonder if this really solves the author problem because by the looks of it , you just have to run meta command and it would run over each of the sub directory. While at the same time , I think I like it because this is what I think people refer to as "modular monolith"

   Combining this with nats https://nats.io/ (hey if you don't want it to be over the network , you could use nats with the memory model of your application itself to reduce any overhead) and essentially just get yourself a really modular monolith in which you can then seperate things selectively (ahem , microservices) afterwards rather easily.

5. mise

   4 143 29,481 10.0 Rust

   dev tools, env vars, task runner

   

   theoretically we could also use https://just.systems/ or https://mise.jdx.dev/ instead of directly calling gh actions but I haven't tried gh actions personally yet , If its really the nightmare you are saying , then that's sad.

6. just

   5 225 34,266 9.2 Rust

   🤖 Just a command runner

   

   theoretically we could also use https://just.systems/ or https://mise.jdx.dev/ instead of directly calling gh actions but I haven't tried gh actions personally yet , If its really the nightmare you are saying , then that's sad.

7. runner

   6 96 6,065 9.2 C#

   The Runner for GitHub Actions :rocket:

   

   I realky wish they supported yaml anchors. That woukd resove one of the gripes, which I share.

   https://github.com/actions/runner/issues/1182

8. gabo

   7 11 128 8.9 Go

   GitHub Actions Boilerplate Generator to avoid common pitfalls (https://ashishb.net/programming/common-pitfalls-of-github-actions/)

   

   There are a lot of subtle pitfalls as well. Like no default timeouts, excess permissions etc.

   I wrote about it in detail https://ashishb.net/tech/common-pitfalls-of-github-actions/

9. gitlab-ci-local

   8 13 3,944 9.1 TypeScript

   Tired of pushing to test your .gitlab-ci.yml?

   

   Oh, yeah, I remember looking at that a while back. I don't recall how much it had implemented at the time but it seems that firecow took a vastly different approach than nektos/act did, going so far as to spend what must have been an enormous amount of time/energy to cook up https://github.com/firecow/gitlab-ci-local/blob/4.56.2/src/s... (and, of course, choosing a dynamically typed language versus golang)

10. bors

    9 3 451 0.0 Python

    Integration robot for buildbot and github

    

    That sounds roughly like what happens for Rust. I write a Rust PR, somebody reviews it, they have feedback, I modify the PR, they're happy, and it passes to bors (originally: https://github.com/graydon/bors) which then tries to see whether this can be merged with Rust and if so does so.

    It is nice to know that if humans thought your change is OK, you're done. I've only committed small changes (compiler diagnostics, documentation) nothing huge, so perhaps if you really get up in it that's more work, but it was definitely a pleasant experience.

    ... and sure enough it turns out that work on one of the bors successors was in fact discontinued because you should just use this GitHub feature. TIL.

11. nx

    10 391 28,893 10.0 TypeScript

    The Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.

    

    Caching and sharing artifacts is usually the main culprit. My company has been using https://nx.dev/ for that. It works locally as well and CI and it just works.

    Our NX is pointed to store artifacts in GHA, but our GHA scripts don't do any caching directly, it is all handled by NX. It works so well I would even consider pulling a nodejs environment to run it in non-nodejs projects (although I haven't tried, probably would run into some problems).

    It is somewhat heavy on configuration, but it just moves the complexity from CI configuration to NX configuration (which is nicer IMO). Our CI pipelines are super fast if you don't hit one of one of our slow compilling parts of the codebase.

    It is quite interesting is that your local dev environment can pull the cached items there were build from previous CI ran-jobs or other devs. We have some native C++ dependencies that are kind of a pain to build locally, our dev machines can pull the built binaries built by other devs (since all devs and CI also share the same cache-artifacts storage). So it makes developing locally a lot easier as well, I don't even remember last time I had to build the native C++ stuff myself since I don't work on it.

12. gha-runner

    11 1 17 1.8 Rust

    Run Github Actions workflows locally or on a custom backend

    

    there's:

    https://github.com/Pernosco/gha-runner

    but I'm not sure how complete it is, and probably doesn't satisfy the author's use cases

13. sparky

    12 7 40 9.0 Raku

    Sparky is a flexible and minimalist continuous integration server and distribute tasks runner written in Raku.

    

    Many if not all mentioned issues derive from the fact that nowadays pipelines are most of the time - YML based - which is terrible choise for programming , you might want take a look at Sparky which is 100% Raku cicd system thst does not have many of mentioned pitfalls and super flexible …

    Disclaimer I am the tool author - https://github.com/melezhik/sparky

Suggest a related project