Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

I agree overall, but you oversimplify the issue a bit.

> can I push this YAML complexity into a script?

- what language is the script written in?

- will developers use the same language for all those scripts?

- does it need dependencies?

- where are we going to host scripts used by multiple github actions?

- if we ended up putting those scripts in repositories, how do we update the actions once we release new version of the scripts?

- how do you track those versions?

- how much does it cost to write a separate script and maintain it versus locking us in with an external github action?

These are just the first questions that pop in my mind, but there is more. And some answers may not be that difficult, yet is still something to think about.

And I agree with the core idea (move logic outside pipeline configuration), but I can understand the tepid reaction you may get. Is not free and you compromise on some things



view as:

This is a whole lot of overthinking for something like

    #!/usr/bin/env bash
    set -ex

    aws send-email ...

Default to bash. If the task is too complex for bash, then use python or node. Most of these scripts aren't going to change very often once stable.

Default to babashka.

I think you are still envisioning a fundamentally incorrect approach. Build scripts for a project are part of that project, not some external thing. The scripts are stored in the repository, and pulled from the branch being built. Dependencies for your build scripts aren't any different from any other build-time dependencies for your project.

I think they framed it accurately and you are instead over complicating. Language for scripts is a decision that virtually every team ends up making regardless. The other questions are basically all irrelevant since the scripts and actions are both stored in repo, and therefore released together and versioned together.

I think the point about maintenance cost is valid, but the thesis of the comment that you are responding to is that the prebuilt actions are a complexity trap.


If build scripts or configuration is shared it might be one of the only times a git submodule is actually useful.

Legal | privacy