feat: only include the architectures supported in version.json

[nschonni]

Description

Motivation and Context

There is likely still some drift between the values in architectures and version.json, but move more towards only including architectures in the Dockerfile that have been marked supported.

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]

Although there is still a Shellcheck issue, I'm marking this as "ready" for a review, because with the upcoming Alpine changes, it probably would be good to make sure that what is marked as supported at the core matches what we're building here.

[nschonni]

I left them out of the diff, but if this is going to land, I'd add the keychanges from #2551 and add them as a separate commit to do one big rebuild at the same time

[MikeMcC399]

As already noted there are several linting errors from ShellCheck that would need to be resolved.

[MikeMcC399]

We don't have an agreed strategy for making changes like this that affect the Dockerfiles but in themselves don't require new Docker builds.

For the @sxa key, Stuart submitted PR #2551 to change the key only (no Dockerfiles). I then did a dummy PR with updated Dockerfiles to run CI tests, which I closed unmerged after the tests were successful.

If that sounds like a good general strategy, we could maybe formalize it separately. If applied here, it would mean submitting a separate PR that only updated the Dockerfile templates and update.sh without updating any Dockerfiles. This PR would remain as a test that doesn't get merged. It's more complicated that way, but avoids the churn of PR creation when not wanted.

[MikeMcC399]

@nschonni

Are you intending to continue with this? I wonder if the script part is really worth the effort if it is being flagged. The architectures don't really change that much, and this is more of a one-off clean-up exercise at the moment I feel.

If you're not able to continue with the PR right now, I would submit individual PRs to drop each of the obsolete architectures, so that they could be individually reviewed.

Let me know, one way or the other!

[nschonni]

Are you intending to continue with this? I wonder if the script part is really worth the effort if it is being flagged. The architectures don't really change that much, and this is more of a one-off clean-up exercise at the moment I feel.

Can't do a one-off cleanup, it needs to be done in the script as the permutations are at the release level inside a template.

I'll try and just suppress or address the last ShellCheck issues if there aren't any other feedback

[MikeMcC399]

Can't do a one-off cleanup, it needs to be done in the script as the permutations are at the release level inside a template.

Understood. I would have just wanted to wipe out the ones that aren't used at all. Your solution is finer-grained than that, I realize now.

[MikeMcC399]

Congratulations on sorting out the scripts! I'll give this approval now.

I'm still unsure about including the generated Dockerfile instances though, because by default that will immediately trigger a PR to release a new version, although the generated Docker images should be no different:

docker-node/.github/workflows/official-pr.yml

Lines 8 to 13 in f2f2bf1

	paths:
	- ".github/workflows/official-pr.yml"
	- "**/Dockerfile"
	- "**/docker-entrypoint.sh"
	- "versions.json"
	- "stackbrew.js"

One way to handle it manually would be to temporarily disable the workflow .github/workflows/official-pr.ym before merging.

Another way would be to clone only the generic files into a separate PR and merge only those changes. The Dockerfile generation would be picked up by any new Node.js release:

• Dockerfile-*-template
• update.sh

The final way would be to do what has been done in the past: merge the PR and then manually close the unwanted PR in https://github.com/docker-library/official-images

I'll leave it to you what you think is best! You have a long history of experience in this repo to make the right decision.

Edit: I made a suggestion in #2564 (comment) for a skip-release label