install bashunit via pinned github action

[staabm]

• install via newly published bashunit github action
• no need to blindly rely on curl ... | bash commands.
• as of now, updates will be shipped by renovate/dependabot like any other action
• we can use a pinned release, so we know which version will be installed
• zizmor will statically analyse bashunit

[staabm]

Hey @Chemaclass,

ondrej just pointed out, that the newly added github action internally uses the "latest" version of bashunit instead of the one "pinned by" the hash we use (in this PR its 38fd81415a622ec084aaf2c7a71a543470581437).

to make this really a pinned version, it would be necessary that the line
uses: "TypedDevs/bashunit@38fd81415a622ec084aaf2c7a71a543470581437"
already implies the underlying bashunit version.
(the hash used is the git commit hash - see TypedDevs/bashunit@38fd814)

in other words, the bashunit version should not be a input for the github action.

does this make sense to you? would this be something you could adjust?

Thanks

[Chemaclass]

Thanks @staabm, good catch on the smell, but the behavior is already deterministic, just badly named.

The action doesn't fetch a rolling "latest" at runtime. install.sh carries a baked LATEST_BASHUNIT_VERSION constant that release.sh bumps on every release, and when version: latest is passed the script keeps that baked tag (no GitHub API lookup happens). So pinning the action by SHA (38fd814…) already pins the exact bashunit version shipped at that commit; latest here means "latest at build time", not "newest now".

That said, you're right that the default: latest naming hides this. I'll make the default a concrete version string in action.yml, bumped by the release script, so the pinned version is visible right at the call site and there's no ambiguity. Tracking on the bashunit side.