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.<p><a href="https://github.com/jstrieb/just.sh/blob/2da1e2a3bfb51d583be0b14969bd81fea696d039/.github/workflows/test.yml#L20">https://github.com/jstrieb/just.sh/blob/2da1e2a3bfb51d583be0...</a>
One cool undocumented GitHub Actions trick I spotted at work was the ability to use wildcards to match repository_dispatch event names:<p><pre><code> on:
repository_dispatch:
- security_scan
- security_scan::*
</code></pre>
Why would you want to do this?<p>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).<p>This allows us to dispatch an event like so:<p><pre><code> {
"event_type": "security_scan::$product_name::$version",
"client_payload": {
"field": "value"
}
}
</code></pre>
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.<p>I tend to prefer either:<p>- Using a build-system (e.g. Make) to encode logic and just invoke that from GitHub Actions; or<p>- Writing a small CLI program and then invoke that from GitHub Actions<p>It's so much easier to debug this stuff locally than in CI.<p>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.<p>This generation will shudder when they are asked to bring discipline to deployments built from github actions.
As long as other readers of the action are aware of what's happening, this seems pretty useful. There's been many adventures where my shell script, starting out as a few lines basically mirroring what I typed in by hand, has grown to a hundred-line-plus monster where I wish that I had real arrays and types and the included batteries in the Python stdlib.<p>I'm definitely not going to use this to implement my company's build actions in elisp.
Github Actions Runner code is pretty easy to read, here's a specific place that define default arguments for popular shells / binaries: <a href="https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/ScriptHandlerHelpers.cs#L18">https://github.com/actions/runner/blob/main/src/Runner.Worke...</a>, it is exported through a method ScriptHandlerHelpers.GetScriptArgumentsFormat.<p>In ScriptHandler.cs there's all the code for preparing process environment, arguments, etc. but specifically here's actual code to start the process:<p><a href="https://github.com/actions/runner/blob/main/src/Runner.Worker/Handlers/ScriptHandler.cs#L331">https://github.com/actions/runner/blob/main/src/Runner.Worke...</a><p>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.
This gives me hope to ease running Go code for CI jobs directly from GitHub workflow YAML files using goeval [1].<p>However goeval doesn't yet have direct support for file input (only stdin), so shell tricks are needed.<p>So far the way is:<p><pre><code> run: |
go run github.com/dolmen-go/goeval@v1 - <<'EOF'
fmt.Println("Hello")
EOF
</code></pre>
but this requires a bit of boilerplate.<p>Disclaimer: I'm the author of goeval.<p>[1] <a href="https://github.com/dolmen-go/goeval">https://github.com/dolmen-go/goeval</a>
Ah I didn't know of the shell directive. Basically an equivalent to #! in shell scripts I guess: <a href="https://en.wikipedia.org/wiki/Shebang_%28Unix%29" rel="nofollow">https://en.wikipedia.org/wiki/Shebang_%28Unix%29</a>
Who would the potential bad actor be here? Someone whose committing to your repo right? I guess the risk is that they add something malicious in the commit and you dont see it. Which is maybe obfuscated to some extent by this little known fact. But all the malicious code would be there in the open just like any other commit.<p>I mean, it seems like it would either take not noticing the malicious code which is always a threat vector. Or seeing it and mistakenly thinking "aha, but you arent actually running it!" and then letting it through based on that (which is of course ridiculous).<p>Or there is some other way to exploit this that I'm unaware of.<p>Edit: OK, maybe this is a little better. Re-write some malicious bash look alike somewhere outside the repo, install it from github actions (make it look like you are updating bash or something) and then its doing the bad thing.
> Any program can be a GitHub Actions shell<p>systemd, echo "1" > /proc/sys/kernel/panic, echo > /bin/bash, etc.