My main argument against this is really that everybody is already familiar with bash just because it's so prevalent in Nixpkgs. So requiring JS instead makes it much harder for people to contribute.

I extended the commit message reasoning / PR body with some new points, one of them addressing this as well. I don't think that's actually true. A lot of people are familiar with bash to write builder. Few people, if any, are familiar with writing safe Bash code for CI purposes. Also, it's not only Bash, you need to do a lot of jq wrangling, too.

Requiring JS does not make it harder to contribute, I believe. Initially, it is a hurdle to take, especially for someone like you, who is one of the few contributors actually having experience with writing CI in Bash. But on the bigger scale, this doesn't change a bit.

You do make good arguments for JS. A large part comes from the fact that you already spent so much effort on it though, when much would've also worked for any other language, including bash.

When we started the migration, I had exactly zero experience with actions/github-script. I had never written a single line in it, nor did @MattSturgeon or @philiptaron have any experience reviewing it. Still, the majority of arguments was already clear back then. I believe the learning was not hard, on the contrary. All the 🤦 moments we had and still have are from GitHub Actions in general, not from using JavaScript to do it. And no, this would have not worked for Bash.

I'd like to encourage you and just try it. I'm sure you will eventually be convinced that this is much better.

In addition to everything that Wolfgang argued above, which I agree with, I have to double down on my own perspective about reviewing the new CI code versus the bash CI code.

The real challenge is that bash has an extensive surface area of implicit behaviors that interact in non-obvious ways. I need to verify proper quoting around variable expansions, understand whether you’re dealing with the test command [ or the bash keyword [[, and trace how exit codes propagate through pipelines and subshells. The language resists static analysis in fundamental ways, so I can’t rely on tooling to catch issues the way I would with strongly-typed compiled languages. Tools like shellcheck are valuable, but they can only catch a subset of potential issues because so much depends on runtime context and the actual data flowing through your commands. And in our CI, even shellcheck isn't readily available at hand.

The documentation landscape also presents challenges. I often need to cross-reference the bash manual, POSIX specifications, and community knowledge bases to determine the semantics of particular constructs are in the first place... let alone whether they’ll behave differently across environments. Complex scripts with heavy use of parameter expansion, process substitution, and pipeline chains require careful analysis to understand both intent and correctness. This isn’t to diminish bash’s utility—it remains an excellent tool for its domain—but effective code review in bash demands a level of detail-oriented scrutiny and deep language knowledge that exceeds what’s typically required for even notoriously "wat‽" languages like JavaScript.

Another significant factor is bash’s limitation to primitive data structures—essentially strings, arrays, and associative arrays. JavaScript provides rich object models where you can encapsulate data with behavior, define clear interfaces, and leverage type systems (even dynamic ones) to make code intent explicit. I see objects with methods, clear data transformations, and structured error handling. In bash, everything ultimately reduces to text manipulation, which means you’re constantly parsing and validating data inline. There’s no .parse() method that returns a well-defined object—instead, you’re using cut, awk, or parameter expansion to extract fields, hoping the input format hasn’t changed. This lack of abstraction makes it difficult to review for correctness because I can’t reason about well-defined types or contracts; I'm always tracking raw strings and their various transformations through the script’s execution flow.​​​​​​​​​​​​​​​​

For this specific domain, I'm in pretty strong agreement that bash is not the right language for future additions.

Two approvals + more feedback in the form of reactions (also by the security team). Let's do it.

Successfully created backport PR for release-25.05:

• [Backport release-25.05] ci/README: add github-script policy #454540