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...

One cool undocumented GitHub Actions trick I spotted at work was the ability to use wildcards to match repository_dispatch event names:

    on:
      repository_dispatch:
        - security_scan
        - security_scan::*

Why would you want to do this?

We centralize our release pipelines as it's the only way to force repositories through a defined reusable workflow (we don't want our product teams to have to maintain them).

This allows us to dispatch an event like so:

    {
      "event_type": "security_scan::$product_name::$version",
      "client_payload": {
        "field": "value"
      }
    }

Then it is far easier to identify which product and version a workflow is running when looking in the Actions tab of our central release repository.

My experience is that the less done in GitHub actions the better.

I tend to prefer either:

- Using a build-system (e.g. Make) to encode logic and just invoke that from GitHub Actions; or

- Writing a small CLI program and then invoke that from GitHub Actions

It's so much easier to debug this stuff locally than in CI.

So an interesting trick, but I don't see where it would be useful.

Our generation shuddered in terror when we were asked to translate a spreadsheet to code while the spreadsheet continued to evolve.

This generation will shudder when they are asked to bring discipline to deployments built from github actions.

You can also trick the default shell 'bash' into running any program.