Automate PR for removing EOL Node.js versions

[nschonni]

Problem

While doing #2100, I realized that our data is probably structured well enough that these PRs could be automated.

Solution

Create a (daily?) CI that:

• Query the version.json for "end" <= Today
• Delete the EOL node in version.json
• Delete any version folders that are no longer in version.json
• Create PR if there is diff

This could probably use https://github.com/nodejs/docker-node/blob/main/.github/workflows/automatic-updates.yml as an example, but probably should be it's own job.

Alternatives to Consider

This happens so infrequently that we don't want to bother automating

[LaurentGoderre]

I think how infrequent and how little change it is, I would vote to not do this. It could prevent cases where the dates change last minute and aren't update here.

[SimenB]

The release schedule exists as a JSON file - we should probably use data from that rather than duplicate its info into our own versions.json file.

https://github.com/nodejs/Release/blob/main/schedule.json

Then we at least won't have stale data to compare to

[wesleytodd]

I am interested in the process on this. Is there a clear way to tell which base OS and Node.js version combinations should exist in the Docker registry? Since it is a manual process, I assume it depends on when y'all have landed those in the past?

The Package Maintenance WG maintains a tool called @pkgjs/nv which is basically a client library for schedule.json and https://nodejs.org/download/release/index.json. I was working on something this morning and think I need the docker builds and realized those files do not contain any information about the docker containers. Came here looking and saw this issue.

So I think there are two things that maybe can come out of this:

1. Use @pkgjs/nv in the process here to decide which versions to build
2. Augment @pkgjs/nv with additional data about which OS versions each Node.js version should have containers for

Thoughts on this?