Any program can be a GitHub Actions shell

1. just.sh

   1 3 238 4.7 Python

   Compile Justfiles to portable shell scripts

   

   I've used this in the past to force bash to print every command it runs (using the -x flag) in the Actions workflow. This can be very helpful for debugging.

   https://github.com/jstrieb/just.sh/blob/2da1e2a3bfb51d583be0...

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. nob.h

   2 5 2,222 8.2 C

   Header only library for writing build recipes in C.

   

4. goeval

   3 3 33 8.6 Go

   Run Go snippets instantly from the command-line

   

   This gives me hope to be able run Go code for CI jobs directly from GitHub workflow YAML files using goeval [1].

   However goeval doesn't yet have direct support for file input (only stdin), so shell tricks are needed.

   Disclaimer: I'm the author of goeval.

   [1] https://github.com/dolmen-go/goeval

5. dhall-lang

   4 127 4,403 4.6 Dhall

   Maintainable configuration files

   

   I'll give a shot at some guiding principals:

   1. Do not use yaml.

   All github action logic should be written in a language that compiles to yaml, for example dhall (https://dhall-lang.org/). Yaml is an awful language for programmers, and it's a worse language for non-programmers. It's good for no one.

   2. To the greatest extent possible, do not use any actions which install things.

   For example, don't use 'actions/setup-node'. Use bazel, nix, direnv, some other tool to setup your environment. That tool can now also be used on your developer's machines to get the same versions of software as github.

   3. Actions should be as short and simple as possible.

   In many cases, they will be as simple as effectively "actions/checkout@v4", "run: ./ci/build.sh", and that's it.

   4. Do not assume that things are sane or secure by default.

   Ideally you don't accept PRs from untrusted users, but if you do, read all the docs very carefully about what actions can run where, etc. Github actions on untrusted repos are a nightmare footgun.

6. actionlint

   5 8 3,475 9.2 Go

   :octocat: Static checker for GitHub Actions workflow files

   

   https://store.dhall-lang.org/Prelude-v23.1.0/JSON/Type.dhall...

   basically, to do recursive definitions, you have to lambda encode your data types, work with them like that, and then finally "reify" them with, like, a concrete list type at the end, which means that all those lambdas evaluate away and you're just left with list data. This is neat and intresting and worthy of learning, but would be wildly overly-complicated for most eng teams I think.

   After hitting this point in the search, I decided to go another route: https://github.com/rhysd/actionlint

   and this project solved my needs such that I couldn't justify spending more time on it any longer.

7. runner

   6 88 5,759 9.2 C#

   The Runner for GitHub Actions :rocket:

   

   Github Actions Runner code is pretty easy to read, here's a specific place that define default arguments for popular shells / binaries: https://github.com/actions/runner/blob/main/src/Runner.Worke..., it is exported through a method ScriptHandlerHelpers.GetScriptArgumentsFormat.

   In ScriptHandler.cs there's all the code for preparing process environment, arguments, etc. but specifically here's actual code to start the process:

   https://github.com/actions/runner/blob/main/src/Runner.Worke...

   Overall I was positively surprised at simplicity of this code. It's very procedural, it handles a ton of edge cases, but it seems to be easy to understand and debug.

Suggest a related project