Enable GitHub Actions workflow to automate new release updates

[wraschke]

This pull request's objective is to fully automate the vNext updates in ci.docker repos for an upcoming release.

Workflow run demonstrating objectives met: https://github.com/wraschke/ci.docker/actions/runs/6669536508/job/18127527479

Resulting pull request: https://github.com/wraschke/ci.docker/pull/20/files

Note that this is a run done only in my fork--that is the environment where I've done all my testing and development.

It's not possible to test this workflow file in origin until they are merged.

And note that this PR introduces only the workflow YML file into main. The script it invokes needs to live in vNext: see accompanying #558.

[leochr]

@wraschke Thanks for the PR. Looks fine to me. Just a comment/inquiry about post-quarterly releases.

[wraschke]

To make this comment accessible/viewable to Leo. I'm responding to his review question:

The release after a quarterly release (version ending in .3, .6, .9, .12) wouldn't have an "old" version. The field is marked as required. Just want to make sure that such scenarios would work fine?

Hi, Leo. "Old version" is supposed to refer to the version that is currently released and present in the Docker files--the one that we're trying to upgrade away from.

For example, let's consider the timeline now: in October, we're preparing for 23.0.0.11; "old version" is 23.0.0.10.

Whenever I run the automation scripts, I always need to specify the "old version" information--otherwise, the scripts don't work.

Should I change the variable and description of workflow textfield to make the input more clear?

[wraschke]

One important thing to note is that the "old" automation scripts never removed the no-longer supported, stale quarterly release directory. This was always done manually; I just confirmed with Chris Potter.

I will try to automate that work in another iteration of this feature.