ci: always run "./update.sh" even if musl is missing

[nschonni]

Description

Security releases are still getting stuck on Unofficial builds, so ensure that the security flag is read from the nodejs.org index.json, not the unofficial-builds version, that is missing till the build is queued.

Motivation and Context

• swap calls to fuction.sh for normal Node.js file operations
• removed assumptions that it only runs on GitHub Actions, and use native Node.js Fetch instead
• Assume the Alpine build might lag
• Read the security flag from nodejs.org instead of unofficial-builds

Testing Details

Example Output(if appropriate)

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.

[nschonni]

Think this probably needs to use something like import.meta.dirname

[nschonni]

Also used the Sync versions of the methods that probably should be swapped

[nschonni]

Marking as Ready, now that the Security releases are all out

[MikeMcC399]

I let Copilot have a look, with the conclusion that it solves the issue you describe. 👍

It did however identify an edge case of updates that combine majors with a mixture of security / non-security. If the intention is to allow the security releases to continue without musl, and block only the non-security releases, instead of exiting completely, then the suggested change was:

https://github.com/nschonni/docker-node/blob/c3fe3eb33b0e1efb68538e08366a55c23f85666a/build-automation.mjs#L131

from process.exit(0); to continue;

I would be happy if the mainstream expected case of a bundle of security updates like 22.x, 24.x & 26.x are handled. If you want to look at the edge case, please go ahead. I'll approve anyway, so you have free hand.

Also, if this is a good opportunity to add some additional logging, then please think about this. It hasn't been clear so far if a release has been identified as security or not in the logs, which are anyway quite sparse.

[nschonni]

Flipped it back to draft, because as I started to add logging, I ended up redoing so much of it. Will see if it makes sense in the end, and maybe to a new PR